That's a good point. Should I revert to something similar like before, or do you have a better idea?
Thanks, christos > On May 5, 2019, at 9:09 PM, Robert Elz <k...@munnari.oz.au> wrote: > > Date: Sun, 5 May 2019 16:38:04 -0400 > From: Christos Zoulas <chris...@zoulas.com> > Message-ID: <41fb59a5-c9e0-4392-bd5c-508e5b80e...@zoulas.com> > > | I did not want to make it smaller, but yes, > | you are right I will remove the slop. > | > | > On May 5, 2019, at 4:30 PM, matthew green <m...@eterna.com.au> wrote: > > | > is the old value useful now? i think your checking against > | > the current limit seems totally valid and obsoletes the old > | > check which was simply some slop over open fds. > > It might matter in a case where a process has lots open files and > then sets its limit lower (and yes, I have done that while testing > that EMFILE errors get handled correctly...) In such a case it > might want to poll more files than the limit allows. > > I also don't believe there's any restriction on including the same > fd more than once (with diffent bits set in events probably) - perhaps > might happen in threaded code when one thread is reading from an fd, > and a diffenent one is writing to it (probably a net connection or tty). > > What would probably be more useful would be to remove the limit, or > simply set a reasonable one, and document it. Its relationship to > open file counts is nebulous at best. > > kre