On Thu, 2009-12-10 at 00:28 +0100, Emanuele Pucciarelli wrote: > > Why do you silently handle EBADFs and ENOENTs? Are those actually > > happening in your system? Dovecot should never close fds before removing > > them from ioloop, other ioloops also log an error if that happens. > > I'll check that again and report back. I'm not sure if I saw an > ENOENT. Does this apply to ioloop-notify as well?
Yes. > > For port_getn() error handling I'd probably do the same as all other > > ioloops: Ignore EINTR/ETIME and treat everything else as fatal. What's > > the idea behind BAD_PORTEV_USER? > > Unfortunately, it's possible (at least in some versions, see [2]) that > port_getn() returns EINTR before updating nget to anything useful. In > this case, the code would see it set to 1 and try to process the > event: it would probably crash immediately, as soon as it tries to > dereference events[0].portev_user to update the refcount. It seems to > be a rare race condition and I haven't witnessed it personally, but > (claimed to be) entirely possible. Oh, so kind of an API design bug. But could BAD_PORTEV_USER be simply NULL? Seems safer than some random memory address that might even be valid. Oh and in notify code your loops use ret, not read_events.
signature.asc
Description: This is a digitally signed message part
