On Thu, Feb 04, 2016 at 12:52:36PM +0300, Georgy Kirichenko
<[email protected]> wrote:
> > That's clearly not true, the most obvious thing (but not the only thing)
> > the callback could do is create some free fds, either by increasing the fd
> > limit, or by freeing some fds.
> I think this can't fix problem,
The point I made was that your original claim was untrue, which I have
shown by giving counterexamples. It's not an exhaustive list. Other
options would be setjmp/longjmp or using another thread and canceling it -
the latter has the advantage of actually catching all such cases, not just
a single case.
> because unprivileged user can't increase fdlimit as he want,
That's an administrative issue.
> and in case of "emergency descriptors" it isn't guaranteed, that freed
> descriptors won't be intercepted by another threads. In my case solution
> shouldn't have any impact on another threads.
"Guaranteed" is a red herring - nothing is guaranteed when you run out of
vital resources (e.g. memory). You have to draw a line somewhere, and libev
draws it where it currently draws it. It's basically the same mechanism that
libx11 uses, which has withstood the test of time.
I'm not convinced that singling out _one_ case of fd exhaustion (or in
general, resource exhaustion) is worth a special case (it doesn't handle
epoll fd creation or event pipe re-creation), given plenty of alternatives
you can implement already.
> I need just return an error, that can be handled by application, in case if
What when there is nothing to return to? The reason for the callback is to be
able to handle exactly these cases.
> something went wrong by libev initialization, avoiding any impact on another
> parts of my application.
libev currently doesn't allocate its pipe on init, but on various other
events. catching one of those is not fixing anything, it's merely
pretending.
> > file descriptors are a limited resource, like memory - you can't fix out
> > of memory conditions by checking at initialisation time and hoping that
> > dynamic allocations later will always succeed.
> Main problem is that ev_async_start tries to allocate limited resource, but
> can't return any error to app.
Right, and it's not the only part of libev that does that, so your patch
doesn't fix the problem at all (and I don't see how a similar approach
could).
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/libev
