> 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[]. > 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.
Sorry to reply to my own mail, but it's worse than I thought. The man page is obviously wrong in the most literal reading (we don't return ETIME if nget is updated...), but after looking at the code, I'm not even sure what it's supposed to be saying. The code in the kernel appears to return early with ETIME without consuming events in some cases, but other times it goes and consumes events even after getting ETIME. See: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/portfs/port.c#1325 Note the check on line 1339. If it falls through because flags = 0 (which it is in the common case for port_getn), we check for events without modifying error. It's unclear if that's intentional - i.e. is the code wrong in addition to the man page or just the man page? -- Dave > > > > 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 networking-discuss@opensolaris.org
