I rewrote much of the kqueue code since the old code didn't handle properly the case when both input and output I/O handlers were added to the same file descriptor with different callbacks. This is done commonly in Dovecot, so I'm wondering why more people didn't complain about problems with it.. :) I don't anyway have access to any BSDs so the code is completely untested. Please test how it works before 1.0rc7 :) http://dovecot.org/nightly/dovecot-latest.tar.gz I'd guess the hangs caused by recent RC versions were because the default was to use notify=kqueue instead of notify=none. I changed this back to none unless --with-ioloop=kqueue is used. There are a couple of things in the code that I'm not completely sure of. The kqueue() manual page says that EV_ADD "modifies" the event if it already exists. What exactly does that mean? Does it mean that the filter is replaced, or that it's ORed into the existing one? The same question for the EV_DELETE, does it delete everything or only those filters given in parameters? The code currently assumes ORing and EV_DELETE deleting only the given filters, since this is what the original code also did. I suppose the data and udata parameters don't matter in EV_DELETE since they weren't given originally in ioloop-notify-kqueue.c either, so I left them that way. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20060816/c227595f/attachment.bin>
configure resulted in: I/O loop method ..................... : poll File change notification method ..... : none Where 1.0.rc6 did: I/O loop method ..................... : poll File change notification method ..... : kqueue What configuration options do you want used? (I am using FreeBSD 4-something.)
Timo Sirainen wrote: I get the following compile error: ioloop-notify-kqueue.c: In function `event_callback': ioloop-notify-kqueue.c:45: error: `ret' undeclared (first use in this function) ioloop-notify-kqueue.c:45: error: (Each undeclared identifier is reported only once ioloop-notify-kqueue.c:45: error: for each function it appears in.) ioloop-notify-kqueue.c: In function `io_loop_notify_add': ioloop-notify-kqueue.c:113: error: incompatible types in initialization ioloop-notify-kqueue.c: In function `io_loop_notify_remove': ioloop-notify-kqueue.c:138: error: incompatible types in initialization declaring an int ret fixed the first error. I'm not sure about the latter two. my configure command: ./configure --without-shadow --localstatedir=/var --with-ioloop=kqueue --with-cyrus-sasl2 --without-gssapi --without-vpopmail --prefix=/usr/local --build=i386-portbld-freebsd5.3 I'm on FreeBSD 5.3. Thanks, Todd
On Wed, 2006-08-16 at 19:17 +0300, Timo Sirainen wrote:> I don't anyway have access to any BSDs so the code is completely > untested. Please test how it works before 1.0rc7 :) > > http://dovecot.org/nightly/dovecot-latest.tar.gzOK, so that didn't even compile. Updated it, how about now? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20060816/58210f65/attachment.bin>
Hi, On Wed, 16 Aug 2006, Timo Sirainen wrote:> On Wed, 2006-08-16 at 19:17 +0300, Timo Sirainen wrote: >> I don't anyway have access to any BSDs so the code is completely >> untested. Please test how it works before 1.0rc7 :) >> >> http://dovecot.org/nightly/dovecot-latest.tar.gz > > OK, so that didn't even compile. Updated it, how about now?ok it compiles now on freebsd 6.1. Not sure if I can get around to fully testing it. Automated tests would help of course. This kind of stuff really needs hard testing to see if its stable. Greetings Christian -- Christian Kratzer ck at cksoft.de CK Software GmbH http://www.cksoft.de/ Phone: +49 7452 889 135 Fax: +49 7452 889 136
Timo Sirainen wrote:> On Wed, 2006-08-16 at 19:17 +0300, Timo Sirainen wrote: >> I don't anyway have access to any BSDs so the code is completely >> untested. Please test how it works before 1.0rc7 :) >> >> http://dovecot.org/nightly/dovecot-latest.tar.gz > > OK, so that didn't even compile. Updated it, how about now? >Just compiled on OpenBSD 3.9 (stable). ./configure --with-ioloop=kqueue --sysconfdir=/etc --localstatedir=/var --without-vpopmail --without-shadow --without-pam So far seems to be working ok (checked with 1.5.0.5 in imap and pop3 , in TLS mode, with cert. auth). Nothing suspicious happening or in logs, as yet.
On Wed, Aug 16, 2006 at 09:09:55PM +0300, Timo Sirainen wrote:> On Wed, 2006-08-16 at 19:17 +0300, Timo Sirainen wrote: > > I don't anyway have access to any BSDs so the code is completely > > untested. Please test how it works before 1.0rc7 :) > > > > http://dovecot.org/nightly/dovecot-latest.tar.gz > > OK, so that didn't even compile. Updated it, how about now?It compiles cleanly on NetBSD 3.x (both with the defaults and with kqueue). I did not yet test it any further though. Geert
Timo Sirainen wrote, On 16.8.2006 18:17:> I rewrote much of the kqueue code since the old code didn't handle > properly the case when both input and output I/O handlers were added to > the same file descriptor with different callbacks. This is done commonly > in Dovecot, so I'm wondering why more people didn't complain about > problems with it.. :) > > I don't anyway have access to any BSDs so the code is completely > untested. Please test how it works before 1.0rc7 :) > > http://dovecot.org/nightly/dovecot-latest.tar.gz > > I'd guess the hangs caused by recent RC versions were because the > default was to use notify=kqueue instead of notify=none. I changed this > back to none unless --with-ioloop=kqueue is used.Just a first thought before I take a closer look: The notify stuff uses kqueue but its functionality is not dependent on ioloop kqueue. It should be possible to use kqueue notify with select or poll based ioloop.> > There are a couple of things in the code that I'm not completely sure > of. The kqueue() manual page says that EV_ADD "modifies" the event if it > already exists. What exactly does that mean? Does it mean that the > filter is replaced, or that it's ORed into the existing one? The same > question for the EV_DELETE, does it delete everything or only those > filters given in parameters? > > The code currently assumes ORing and EV_DELETE deleting only the given > filters, since this is what the original code also did. > > I suppose the data and udata parameters don't matter in EV_DELETE since > they weren't given originally in ioloop-notify-kqueue.c either, so I > left them that way.-- VH -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 542 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20060816/cef34d6f/attachment.bin>
I've been using this for about an hour. No stale imap processes yet but I have this in my log... Aug 16 17:56:40 loveturtle dovecot: imap-login: Login: user=<turtle>, method=plain, rip=216.89.228.115, lip=216.91.90.11, TLS Aug 16 17:56:45 loveturtle last message repeated 3 times Aug 16 17:56:45 loveturtle dovecot: imap-login: kevent(EV_DELETE, 9) failed: No such file or directory Aug 16 17:56:45 loveturtle last message repeated 9 times Aug 16 17:56:45 loveturtle dovecot: imap-login: Sending log messages too fast, throttling.. Aug 16 17:56:45 loveturtle dovecot: imap-login: kevent(EV_DELETE, 9) failed: No such file or directory Aug 16 17:56:46 loveturtle last message repeated 5 times No idea what that means but I thought I'd share. :-D This is on FreeBSD/amd64 6.1-STABLE
On Wed, 16 Aug 2006, Timo Sirainen wrote:> of. The kqueue() manual page says that EV_ADD "modifies" the event if it > already exists. What exactly does that mean? Does it mean that the > filter is replaced, or that it's ORed into the existing one? The sameIIUC the filter fields are updated to match the new values. i.e. the later event effectively replaces the earlier event.> question for the EV_DELETE, does it delete everything or only those > filters given in parameters?Again, IIUC, only the event that EV_DELETE is set upon. Recall taht an event is identified by a filter, ident pair.> The code currently assumes ORing and EV_DELETE deleting only the given > filters, since this is what the original code also did.I don't think the ORing is correct. I can check if you like. Andrew