This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: sigframe query
- From: Christopher Faylor <cgf at redhat dot com>
- To: cygwin-developers at cygwin dot com
- Date: Sat, 3 Aug 2002 19:34:51 -0400
- Subject: Re: sigframe query
- References: <030a01c23b3e$3edf2de0$6132bc3e@BABEL>
- Reply-to: cygwin-developers at cygwin dot com
On Sat, Aug 03, 2002 at 11:36:44PM +0100, Conrad Scott wrote:
>The "how-signals-work.txt" file contains the following paragraph:
>
>> If sigsave seems to be available, then the frame
>> information for the main thread is inspected.
>> This information is set by any cygwin function
>> that is known to block (such as _read()),
>> usually by calling 'sigframe thisframe (mainthread)'
>> in the cygwin function. This call sets up information
>> about the current stack frame of an executing cygwin
>> process. Any function which uses 'sigframe thisframe'
>> should be signal aware. It should detect when a
>> signal has arrived and return immediately.
>
>But in wandering back and forth in the code I've noticed several
>functions that have a sigframe but are neither slow nor
>signal-aware; for an extreme case, see the isatty function in
>"syscalls.cc".
>
>Is there any good reason to add sigframe to non-blocking
>functions? or is it something that could be "optimized" away? or
>should "how-signals-work.txt" be updated?
I've updated how-signals-work.txt (q.v.).
cgf