Jeff Trawick wrote: > If an event is triggered at about the same time as a timeout expires, the > port_getn() libc interface can return with > > retcode: -1 > errno: ETIME > number of events: updated to > 0 > > The -1/ETIME must be ignored and the event(s) processed, as the kernel will > not report it again until after a subsequent call to port_associate(). > > I've seen it on 2009.06 and S10U7. > > The man page has two descriptions for ETIME: > > The port_get() and port_getn() functions will fail if: > ... > ETIME The time interval expired before the expected > number of events have been posted to the port. > ... > The port_getn() function will fail if: > ... > ETIME The time interval expired before the expected > number of events have been posted to the port > (original value in nget), or nget is updated with > the number of returned port_event_t structures in > list[]. > > The second description of ETIME is perhaps unclear (is it "before A or B > occurs" or "before A occurs; otherwise"); regardless, neither description > mentions this behavior.
I think it's not quite either of those. I think it's saying that if "the time interval expire[s] before the expected number of events have been posted to the port", then it may return with ETIME or it may set *nget to the number of returned structures. In this case, it's an inclusive "or". The wording is confusing at best. As Meem points out, even if the wording were fixed, the semantic is still a bit odd. > Can anyone advise on how an app can avoid pitfalls in this area regardless of > *Solaris level? Empirically and corroborated by the man page (if you assume what I said above about the wording of the ETIME specification), if you got no error or ETIME, you must check *nget for events. It's unclear whether the value of *nget is defined for EINTR, but I would expect it should be treated the same as ETIME. Of course, there's no way to err on the side of caution here, since the failure mode of getting this wrong in either case is disastrous (missing events or consuming garbage). The other documented errors (EBADF, EBADFD, EFAULT, EINVAL) are programmer errors you should always be able to avoid and you should probably assume that you got zero events in those cases. -- Dave > I will open a bug at bugs.opensolaris.org to fix the code or the doc, unless > for some reason shared here it isn't needed or there is a better way to > resolve the issue. > > Thanks! -- This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
