About to check in a big signal handling patch
Sat Nov 29 00:56:00 GMT 2003
On Wed, Nov 19, 2003 at 08:31:39PM -0500, Christopher Faylor wrote:
>I'm about to check in YA rewrite of the signal handling code. This
>implements some of the logic needed to handle signals-to-threads and
>(ta da) sigwait.
>The code isn't perfect yet and still requires some tweaking. I'm not
>entirely wild about certain implementation details -- alternatives are
>still occuring to me at 2AM as I'm drifting off to sleep, on my thinking
>pedestal, and in the shower. I just need to get this checked in so that
>I can start getting some revision control.
>When I'm done, I will have siginfo stuff working as well as some
>rudimentary timer_* and clock_* implementations.
>So, no bug reports on it yet. I'll let you know when I think it is
This is checked in. For those familiar with the code, there are some
obvious changes. sigframe and sigthread are now gone. cygwin.def is
generated on the fly by a perl program, so perl is *really* a necessary
requirement for cygwin builds now. Functions exported in cygwin.din now
may have an extra field at the end, like this:
SIGFE means "Add a signal front end to this export".
NOSIGFE means the reverse.
The default is SIGFE.
The signal front end is the replacement for sigframe. It puts a wrapper
around any function call which could potentially spend non-trivial
amounts of time in the kernel, via "ReadFile", "WaitFor*Object*",
"CreateFile", etc. The wrapper detects when a signal has been called
and invokes the signal handler, if required.
The wrappers are generated by reading cygwin.din file and producing (via
the gendef perl script) an assembly file which contains the needed code
as well as a variant of the signal code that used to be in exceptions.cc
and code to provide the longjmp function. The old longjmp source file
is now gone. This code makes use of a new _threadinfo structure which
manifests automatically as a thread-local "_my_tls" structure. You'll
see _my_tls used throughout cygwin now.
_my_tls lives at the bottom of every thread's stack and contains all
sorts of information about the thread and its signal state -- with more
information to come. While this method seems to work pretty well, I am
somewhat worried that it may not be as robust as it should be. I guess
we'll see when people start using the snapshot.
I have written a script which I can use to figure out what functions
need to be SIGFE and what don't but, if in doubt, when adding functions
to cygwin.din, it should be safe to use SIGFE in most cases or just go
with the default. I'll run the script over cygwin from time to time
to make sure that cygwin.din is accurate.
I have also checked in a semi-working version of sigwait(). I haven't
tested it extensively but I do intend on checking in a test suite change
for this soon. I'm not interested in hearing if this works or doesn't
I'll post more updates about what I've done as they occur to me. It
is a relief to finally check this in as I've been sitting on this code
for some time and didn't want to progress further without getting stuff
into cvs. Further, in this case, means implementing a large portion of
the rest of the SUSv3 signal handling capabilities.
More information about the Cygwin-developers