> On Aug 11, 2023, at 3:09 PM, Tobias Nygren <tnn%NetBSD.org@localhost> wrote: > > On Fri, 11 Aug 2023 18:52:41 -0000 (UTC) > christos%astron.com@localhost (Christos Zoulas) wrote: > >> In article <ZMihOin2SWeuO5Y5%homeworld.netbsd.org@localhost>, >> nia <nia%NetBSD.org@localhost> wrote: >>> On Mon, Jul 31, 2023 at 07:18:38PM -0700, Jason Thorpe wrote: >>>> Anyway, like I said, I think the best way forward is to make it >>> possible for kq descriptors to be inherited? it?s a little tricky >>> because of some of the wacky stuff kqueue can track, but I think NetBSD >>> can lead on this and define a set of semantics that makes sense. >>> >>> Can we agree on renaming the header to sys/epoll_compat.h? >> >> I see that you removed with without further discussion which is not the >> way we do things on NetBSD. Do you have an example where the epoll emulation >> breaks, because either forking matters or the implementation is >> incorrect/different? > > Some examples of packages where forking _could_ have implications and > are not even possible to audit due to undefined number of downstream > consumers, some possibly outside of pkgsrc: > > python, libevent, apr, libev Thank you for the explanation So is the Illumos implementation similar to ours? Does it have the same fork limitation? I.e. is it built on top of kqueue, or something else? I think that it is better in the long run to have a more portable fix (that is not Illumos-specific) that specifies to prefer kqueue over epoll if both are available. Did we see any actual breaks with our implementation? > >> I would agree on principle that it is better to use kqueue on BSD systems, >> but if it is not broken, why not advertise it? > > pkgsrc had a lots of issues with epoll getting picked up on Illumos and > don't want to add more patches to deal with exceptions. > > I see your point but I also don't see the point of rushing this > feature in by default and leaving pkgsrc developers and users to > deal with potential fallout, knowing there are rough corner cases. > > If it can be agreed that we put back the header under a different name > that would be great. > Well, then it will not be used. Do you have a list of the packages affected? christos
Attachment:
signature.asc
Description: Message signed with OpenPGP