Actions
Bug #11910
openport_getn fails with ETIME, even though events are delivered
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 of1
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
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