On Wednesday, February 3, 2016 1:07:03 PM MSK Marc Lehmann 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, because unprivileged user can't increase fdlimit as he want, 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.
I need just return an error, that can be handled by application, in case if something went wrong by libev initialization, avoiding any impact on another parts of my application. > How does the patch fix this? When libev needs a pipe (or similar) at > runtime and doesn't have enough fds, it will run into the same or similar > problems. Proposed patch adds new flag to loop creation, that tells about early evpipe alocation. If libev can't successfully handle this (create eventfd/pipe at ev_loop_new), then its just return null. If all is ok, then ev_async_start won't abort my app, because evpipe is already allocated. > 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. _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/libev
