This is the mail archive of the
cygwin-developers@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: Contemplating signal changes, but...
- To: Chris Faylor <cgf at cygnus dot com>
- Subject: Re: Contemplating signal changes, but...
- From: Mumit Khan <khan at NanoTech dot Wisc dot EDU>
- Date: Tue, 23 Nov 1999 00:28:08 -0600
- cc: cygwin-developers at sourceware dot cygnus dot com
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