On Thu, May 24, 2012 at 07:40:27PM +0400, Denis Bilenko <denis.bile...@gmail.com> wrote: > > behavious is deterministic right now - when you want to do your own signal > > handling, you e.g. block/ev_default_loop/restore/unblock, and that is much > > harder (if possible at all) to do otherwise. > > It's not much harder if you really want to do it that way. Just start > a dummy child watcher after initializing the loop - that will trigger > the signal handler installation. However, you should not need to do > it. Instead, just don't use child watchers.
Right, but it's unnecessary complication nevertheless. > My point is that the mere presence of "ev_child_start()" call in your > code declares the intent of using libev's child reaping over any > other. ev_child_start signifies the desire to get child notifications. I doubt a program cares how it's implemented a slong as it works. > If you don't have ev_child_start() in your code, then libev > won't install a signal handler so there's no need for specific order > of init calls or for undoing SIGCHLD installation. That can already be done by disabling child watchers when compiling libev. libev will not tinker with SIGCHLD in that case. If child watchers are not disabled then it's effectively impossible to know whether it will be called in the future or not, and then libev needs to install a child watcher. > I cannot imagine a case where someone would disable libev's child > reaping and then proceeds to use child watchers. Right, if libev's child reaping is *disabled* then you can't use child watchers, because the necessary functions aren't even defined. > Can any one give me a non-hypothetical example of this? No, because it'S nonsensical. I can give you a real world example of where somebody wnats to take over child reaping over libev - the example you gave, when you want to keep ev_child functionality working inside libev but let the child reaping be done by another library or piece of code, for whatever reason. In this acse, one library has to give, and libev cna either feed child events to the other library, or some code needs to feed it to libev. > I know you can feed events to a watcher, but if you're only feeding > events to a watcher, you no longer care which type of watcher it is, so > use any other than child. Well, I do care which watcher I feed events to, so what you say is already wrong. I think in general when you feed events to a watcher you do care very much about that watcher. > Here's a more important case: the libev's libevent emulation. > > Currently, it reaps children, which makes it incompatible with > libevent programs that have their own child management. libev is also incompatible with programs that define their own ev_child_start function. libevent emulation doesn't mean that libev only implements libevent interfaces and nothing else, it means it implements libevent interfaces (but also libev interfaces). > With the patch > it all works out naturally - the libevent-only program will never call Your patch implements a race condition and makes child weatchers unreliable (i.e. they will never be called sometimes). To fix your patch you'd have to add extra checking code. Your patch also breaks *existing* libev programs. Your patch doesn't help any existing programs that work with libevent and libev. As such, this argument is rather weak - your patch would cause a lot more breakage than it would be helpful for. > I guess you can fix it following your own advice: make event_init() do > block/ev_default_loop/restore/unblock dance. In most cases you you only have to order things right, first initialise the default loop, then install your handler, as opposed to the other way round. So making it work requires zero overhead in typical cases. > However, if you defer signal installation it just works - no > workarounds necessary. Well, it obviously doesn't work - the child handler must be in place before ev_child_start is called (specifically, it must be called before forking). > The new loop option would not help me unless there is also a function > to start child reaping at any time. That would also cause a race condition, causing *the other* event library to lose child signals. It is unfortunate that unix is designed as it is w.r.t. signals, but I think libev makes it pretty easy to work around these limitations while maintaining maximum efficiency. As has been explained before, you have yet to make an actually workign proposal for what you want to achieve. Your patch, as has been pointed out to you before, simply doesn't work at all. So before talking about pros and cons of some hypothetical solution and breaking backwards compatibility, we first would need to have an indication that a solution is even possible. The only known solution is what's implemented by libev at the moment. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev