[Dovecot] Patch: event port-based ioloop and notify

[Timo Sirainen]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20091209/cd8f432a/attachment.bin