This is true , the manpage warns about some issues with epoll, that occur also on Linux.
But I suppose that from a pragmatic point of view, any API has its pro's and con's. So overall I like the fact that Illumos offers the 'epoll feature'. This seems like a feature to me .. not a problem and not something that should be disabled. It works. The OpenSmalltalk VM uses epoll and I find it executes the SUnit tests well, with epoll enabled. From what I understand from the OpenSmalltalk developer, epoll should be preferred over select or poll, when using a large number of connections. That is at least the opinion of some people in the OpenSmalltalk community on Linux. Whereas OpenSmalltalk supports epoll (and I keep it explicitely turned on on OpenIndiana as well), this can be useful for example for games or any application software written in Smalltalk, that handle a large amount of TCP/IP connections. So for example if anyone is investigating issues with large amounts of connections, perhaps it would be interesting to hear about performance differences, between dovecot running with poll and dovecot using epoll. Also if there truly is a problem between epoll and chroot, then it could be an idea as a test to first disable chroot. Regards, David Stes ----- Op 12 feb 2022 om 23:48 schreef toasterson [email protected]: > Hello > > A quick quote I want to have people keep in mind from the epoll manpage > 'man epoll' > > tl;dr epool is for compatibility purposes it is not intended as a full > features replacement. Please do not use it if possible. It works but > there will be dragons. > > ``` > The epoll facility is implemented for purposes of offering > compatibility to and portability of Linux-borne applications; native > applications should continue to prefer using event ports via the > port_create(3C), port_associate(3C) and port_getn(3C) > interfaces. In > particular, use of epoll in a multithreaded environment is > fraught with > peril; even when using EPOLLONESHOT for one-shot events, there > are race > conditions with respect to close(2) that are unresolvable. (For > more > details, see the aborted effort in Linux to resolve this via the > proposed EPOLL_CTL_DISABLE operation.) The event port facility > -- like > the BSD kqueue facility that inspired it -- is designed to deal with > such issues via explicit event source dissociation. > ``` > > Greetings > Till > > On 12.02.22 17:37, Bob Friesenhahn wrote: >> On Sat, 12 Feb 2022, Stephan Althaus wrote: >>> >>> In the snipplet that Mr Al Slater communicated, it looks like there >>> are linux-specific epoll details that are not working with illumos. >>> Apples and apples can be different :-) >> >> This is quite possible. I should mention that I am running Dovecot in a >> zone. I am not quite sure if I am actually using chroot. >> >>> Have a nice day ! >>> P.S. After several weeks of cloudy misty weather the sun is back again >>> here in Germany. Welcome!! >> >> Nice to hear. >> >> Bob > > _______________________________________________ > oi-dev mailing list > [email protected] > https://openindiana.org/mailman/listinfo/oi-dev _______________________________________________ oi-dev mailing list [email protected] https://openindiana.org/mailman/listinfo/oi-dev
