Project

General

Profile

Actions

Bug #11910

open

port_getn fails with ETIME, even though events are delivered

Added by Joshua M. Clulow almost 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

By historical accident, port_getn can fail with ETIME even if it has modified the list[] and *nget arguments to deliver some set of events.

Some argument has been made in the past against fixing this, because it will mean software written against new versions of illumos will not hit (and need to deal with) this edge condition. I don't think that's a very good argument, for at least two reasons:

  • Oracle fixed this in Solaris 11, as far as I can tell, so there are at least some systems with an otherwise compatible port_getn(3C) that no longer exhibit this defect
  • It's extremely subtle, and you can even hit this with an nget value of 1 if your timeout is short enough and you get unlucky. I most recently found an instance of this in the Go runtime -- it's pretty clear that people are going to keep making this totally understandable mistake in perpetuity

I think we should, if we've delivered any events at all (and thus modified the arguments) just return success for this call. We could also update the manual page to more explicitly discuss the previous behaviour, perhaps in NOTES.


Related issues

Related to illumos gate - Bug #14912: non-blocking port_get() returns 0 when there are no eventsNew

Actions
Actions #1

Updated by Robert Mustacchi about 1 year ago

  • Related to Bug #14912: non-blocking port_get() returns 0 when there are no events added
Actions

Also available in: Atom PDF