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.