This is the mail archive of the
cygwin-developers@sourceware.cygnus.com
mailing list for the Cygwin project.
Contemplating signal changes, but...
- To: cygwin-developers at sourceware dot cygnus dot com
- Subject: Contemplating signal changes, but...
- From: Chris Faylor <cgf at cygnus dot com>
- Date: Mon, 22 Nov 1999 22:19:21 -0500
I'm contemplating changing the signal handler in some fundamental
ways. I figure it's time since I've essentially rewritten it three
times since 1997. I've been stabilizing things a lot in the snapshots
but I have never liked the performance hits that I"ve been introducing.
To implement my plan, I need to have some quickly available per-thread
memory. I won't go into details, but basically what I'm looking for is
to use the base of the stack for fast per-thread storage. I can
guarantee that the stack has space available for me down there when I
control thread creation but I can't guarantee this when I haven't
created the thread or when the cygwin DLL is being dynamically loaded.
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.
Opinions?
cgf