Jeff Trawick wrote:
Nicolas Williams wrote:
On Wed, Aug 19, 2009 at 05:57:04PM -0700, David Pacheco wrote:
Nicolas Williams wrote:
To my reading you have these possible conditions:
- max == 0 and port_getn() returns 0 -> *nget will have been set to the
number of events available.
Except when you hit 6455223. This unlikely case occurs when some
events on the port are not deliverable to the calling thread (e.g.,
async i/o completion after a fork in the child process). This is not
relevant to this discussion, but it's worth noting that there are
multiple edge conditions not handled well by the current implementation.
Oh, ick.
- port_getn() returns 0, or it returns -1 && errno is one of ETIME,
EINTR, or EBADFD -> events may have been consumed and placed in
list[], and *nget will have been set to the number of consumed
events.
EBADFD can't return with events.
Ah, I misread the code. The same applies to EINTR, as you point out.
I don't understand the comment here about EINTR. As far as anyone knows,
is it possible to get EINTR with an event, as David suggests in the
previous e-mail? ("It's unlikely that EINTR would return with events
because usually we'll bail out at line 1338, but maybe we can loop
through it multiple times having consumed events the first time and
gotten EINTR later. ")
I didn't look at the code closely enough to say for sure. I know that we
sometimes call the port_getn() kernel function multiple times for a
single port_getn syscall invocation. If we can leave a port_getn()
function call having consumed some events but reenter in order to
consume more, then you could get EINTR with events...
-- Dave
--
David Pacheco, Sun Microsystems Fishworks. http://blogs.sun.com/dap/
_______________________________________________
networking-discuss mailing list
[email protected]
