Re: hang in sig_wait waiting for debug lock

[Christopher Faylor <cgf at redhat dot com>]

On Sun, Sep 08, 2002 at 08:41:51PM +0400, egor duda wrote:
>CF>I don't see this either.  If the table is populated with handles from
>CF>another process that don't exist in this one then that's a bug.
>
>It's clearly so. And enabling setclexec() removes it.

Well, I just walked my dog around the block and I don't see it
happening so I guess it is somehow related to my dog, too.

>I can guess, that it's not the way things were supposed to work, right?

Come on!  Unless you can point to an actual flow of control which
is causing the problem, turning random things on and saying "Wow!
That fixes the problem!" is just voodoo.  It isn't computer science.

If you don't want to understand what's going on then that is perfectly
fine.  However, please don't just assume that if turning on an ifdef
causes a problem to apparently go away that you've done anything more
than add an additional delay to cygwin or moved something to a different
memory location or something.

I am not saying that handles aren't somehow being inherited from
a parent process (which is the only way I can conceive of something like
this happening) but you haven't proved that to be true until you've
pointed to an actual handle for which this is a problem.

Turning on this ifdef causes other random problems.  It is not a solution
for anything.

>CF> Possibly.  Are you seeing system_printf output in your failing case?
>
>Yes, but it looks that it not full. Actually, pipe hasn't to be filled
>up. After WriteFile() we call FlushFileBuffers (). Documentation on
>FlushFileBuffers states that if handle is a pipe then the operation
>blocks until pipe peer reads _all_ data from pipe. Commenting
>FlushFileBuffers did helped in my case -- system_printf()s are not
>blocking process now.
>
>Yet i suppose the right way is to always unlock debug muto as fast as
>possible, i.e., before calling debug_printf() and stuff. As far as i
>understand, muto is protecting handle list, so we must hold it while
>and only while we're messing with it. That should be safe.

Possibly.  Personally, I'm much more bothered by the fact that there
are system_printfs at all.  AFAICT, you only mention this in passing
but a system_printf is an indication of a problem in cygwin.

cgf