> > It works fine without multithreading, so how is it libev?
> >
> I also considered this - as I already mentioned. I didn't get any
I explaiend the facts to you, and you can look them up easily online
too. If you insist on your non-fatc based opinion, that is your right.
> The only solution I'm aware of is using a custom SIGCHLD signal
Solution to *what*?
> handler and activating an async watcher when the signal handler
> gets invoked. This is like simulating an ev_signal.
> Is this the way I'm supposed to go under these circumstances?
Special requirements that rely on unportable behaviour might require
special implementations, yes. This is primarily your problem, the best
that libev can do is provide you the ability to do it, which is clearly
does.
> That's true, there are no segfaults. But imagine libev or some other
> library would always "ignore" SIGCHLDs, maybe repeatedly to prevent
> the user from fixing the handler. waitpid() wouldn't be able to
> reap children anymore. This would be documented waitpid()
> behaviour, too.
If libev gave you the option to do it either way, that would be fine, no?
I fail to see your point. It's not as if libev forced this behaviour on
you.
> I would think that a library with such side-conditions, effectively
> breaking a documented system call is poorly designed.
You know that this is a lie, so why do you repeat it? All you do here now is
trolling: neither waitpid nor system are broken by libev in any way
whatsoever, you know that, and repeatedly claiming the opposite is simply not
acceptable.
If you want to troll, go elsewhere.
> > > Making the mechanism asynchronous/non-blocking, would
> > > require major code refactoring and make conceptually
> > > simple code dis-proportionally harder to read.
> >
> > Seems like an empty claim - can you back it up?
>
> Yes. Usually you're using system() for programs that
[...]
libev doesn't force you to do that, you can also rovide your own signal
handler, _as you well know_.
Since you can't back up your claim, I'll consider it dropped.
> Let's not talk about the problems you would have when
> using that mechanism from a thread that hasn't got the
> default loop (the only one supporting signal/child
> watchers).
There are many well known problems with multihreading - you can't fork and do
soemthing nontrivial anymore, system, read, close etc. all suddenly have race
conditions, signal handlign is order of magnitudes more complex etc.
All you do is whine about that and want libev to somehow solve the problem
for you. But the problem is multihreading, and that simply requires harder
and more code. Whining doesn't help you, you need to sit down and face the
reality: if you use threads, your code gets more complicated. libev can't
magically fix that for you, and trolling here by making repeated wrong
claims is not going to win me over in any way either.
--
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
