This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

sigframe query


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?

// Conrad




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]