Re: Contemplating signal changes, but...

[Chris Faylor <cgf at cygnus dot com>]

On Tue, Nov 23, 1999 at 12:28:08AM -0600, Mumit Khan wrote:
>Chris Faylor <cgf@cygnus.com> writes:
>> I can probably put a front-end on CreateThread to work around the
>> problem with people creating threads but I was thinking of just
>> turning off signals entirely when the Cygwin DLL is dynamically
>> loaded.  I could also just revert to the old method of delivering
>> signals but that would be a little more work.
>> 
>> I wanted to see how people (i.e., Mumit) felt about the idea of
>> signals being inoperative in a dynamically loaded cygwin.  I don't
>> think that this is a big deal but I don't know for sure.
>
>I finally sat down and redid the -mno-cygwin support to avoid the
>code duplication, and I now know that getting signals to work
>*reliably* for non-cygwin apps (loaded dynamically without crt0 
>support) is going to be awkward. The trouble is that singal handling 
>almost requires (unless you don't mind non-deterministic bugs ;-) 
>that the startup waits on the signal thread; now, this is not possible
>due to serialization of LoadLibrary, and so I'm in favor simply
>saying that signal handling is not going to work for non-cygwin
>apps loading Cygwin DLL.

That's right.  I'd forgotten about this serialization problem.  I guess
we could just add a Sleep (200000) to the LoadLibrary part.  That should
work.  :-)

>If you think about the mno-cygwin "customers" of Cygwin, it's mostly 
>extension DLLs for proprietary systems -- Java JNI, Matlab mex,
>Excel DLLs, Netscape/IE plugins -- and we just have to face the fact
>that Cygwin just can't be the end all and be all.
>
>I believe that getting signal handling to work better in Cygwin should 
>take far higher precedence than non-cygwin ones. There, I said it ;-).

Yay!  Thanks, Mumit.

So, you can rip signal initialization from your code.  We'll have to
add a flag to sig_send() (and probably to the pinfo class) to indicate
that a process is unsignable, too.

FWIW, I don't think that signal handling is broken in any way in the
snapshots.  I do think that the current incarnation probably causes
problems under Windows 95/98 and is slower than it has to be but
(with one possible exception) everything seems to be working correctly
in recent snapshots.

The basic problem with signals is that, unlike a standard UNIX OS,
cygwin itself can be interrupted by signals, causing all sorts of
resource leaks.  So, I've been carefully putting signal blocks all over
the the cygwin code.  These work, but essentially what I'm doing is
saying "Hold off on sending signals for a while." then when I'm finished
with a "critical section" I say, "Ok.  You can send signals now.  Scan
the signal queue." That adds a synchronization point that is, in 99% of
cases, not required.

That's what I'm trying to eliminate.

cgf