Mail Archives: cygwin-developers/1999/11/23/01:28:24
Chris Faylor <cgf AT cygnus DOT 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
- Raw text -