Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Message-ID: <030a01c23b3e$3edf2de0$6132bc3e@BABEL> From: "Conrad Scott" To: Subject: sigframe query Date: Sat, 3 Aug 2002 23:36:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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