On Wed, Aug 19, 2009 at 02:29:44PM -0700, Peter Memishian wrote: > > ETIME is returned if the timer expires. Regardless of whether ETIME > > happens, *nget gets updated to the number of events returned (if neither > ETIME > > nor EINTR occur, and *nget <= max, then *nget will not be modified, of > > course). > > > > Think of ETIME/EINTR not as an error but as a supplementary bit of > > inforation: port_getn() always returns, via the nget input/output > > argument, the number of events fetched, and ETIME/EINTR merely indicate > > whether a timeout or signal interrupted the wait for more events. > > It may be too late to fix this, but I think this is a flawed aspect of the
IMO it is too late. What we could do is make sure on EINVAL/EBADF *nget gets set to 0. That would mean that the only error the app has to check for before checking *nget is EFAULT (EFAULT is probably so fatal that the app should abort()). > API. It should return 0 if any events were received in the time alotted; > the caller can then check *nget to determine how many were actually > received. That is, ETIME should be relegated to a hard failure of > receiving no events; pressing it into service for partial failure only > makes programming to the API more error-prone. That would require re-queing events. Any errors while trying to do that would result in lost events. IMO, it's better to not risk that. The only error resulting in lost events, right now, is EFAULT, and that's entirely avoidable, and probably fatal to callers whenever it occurs (i.e., they should probably abort()). The fact that there are other errors that don't consume events but don't update *nget is what's really annoying. That is something we could fix. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
