Re: Contemplating signal changes, but...

[Mumit Khan <khan at NanoTech dot Wisc dot EDU>]

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.

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 ;-).

Regards,
Mumit