Re: Another race in signal handling

2008-01-21 Thread Marc Lehmann
On Mon, Jan 21, 2008 at 11:25:49AM -0500, Chris Shoemaker [EMAIL PROTECTED] 
wrote:
 I figured that describing the exact time when interuption by a signal
 causes signal watchers to be indefinitely delayed would be helpful,

Again, it would have been helpful when you had done that, but instead you
came up with an obviously wrong (because it doesn't match the code)
explanation that is not helpful to anybody.

A good explanation is actually better than a testcase, but a wrong one is
simply absolutely useless, while a testcase is a tedious but sure way to
find bugs.

 but if you find testcases more helpful, I'm very glad to oblige.

In this case, it is the only thing you delivered, so there is no more
helpful here - the choice is between an explanation that has nothign to do
with the code or the problem, or a testcase. Given that choice, it is obvious
that a testcase is more helpful.

 Here it is

I cannot reproduce that with the current (CVS) version and various
settings for the interval timer, but it looks like a race condition that
was recently fixed in libev regarding forking and signal delivery (where
signal delivery could indeed be delayed).

Your fix of removing gotsig only has the effect of shrinking the time
window of this problem occuring, it doesn't fix any underlying issue at
all.

You really shouldn't hack around in the code without understanding it. It
really is best to let people fix it who understand it, lest you will run
blindly into problems that are much harder to debug (because much rarer).

It is, however, your right to hack around in libev, and if you feel you
must add bugs to it, or obfuscate existing bugs without fixing them, you
should do it.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  [EMAIL PROTECTED]
  -=/_/_//_/\_,_/ /_/\_\

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev


Re: Another race in signal handling

2008-01-21 Thread Chris Shoemaker
On Mon, Jan 21, 2008 at 06:39:12PM +0100, Marc Lehmann wrote:
 On Mon, Jan 21, 2008 at 11:25:49AM -0500, Chris Shoemaker [EMAIL PROTECTED] 
 wrote:
  Here it is
 
 I cannot reproduce that with the current (CVS) version and various
 settings for the interval timer, but it looks like a race condition that
 was recently fixed in libev regarding forking and signal delivery (where
 signal delivery could indeed be delayed).
 
 Your fix of removing gotsig only has the effect of shrinking the time
 window of this problem occuring, it doesn't fix any underlying issue at
 all.

I just tried with the current CVS version.  I ran the program 6 times
and the longest it ran was 18 seconds.

What I'm really wondering is: what purpose does the global gotsig
serve?  I've really tried to understand, but I just can't.  Please
explain it to me.  Thanks.

-chris

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev