delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/09/08/21:51:46

From: dahms AT ifk20 DOT mach DOT uni-karlsruhe DOT de
Subject: RE: Signal handling - HELP!
8 Sep 1997 21:51:46 -0700 :
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <009BA04C.9BE841C0.22861.cygnus.gnu-win32@ifk20.mach.uni-karlsruhe.de>
Original-To: sos AT prospect DOT com DOT ru
Original-CC: gnu-win32 AT cygnus DOT com, dahms AT ifk20 DOT mach DOT uni-karlsruhe DOT de
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Hi Sergey, you wrote:

: Ian Collins wrote:
: > When a signal (e.g. SIGALRM) is triggored while in certain system calls
: > (e.g, read), the POSIX signal definition states that after completion of
: > the signal handler, the system call can be made to continue (SA_RESTART)
: > or to return with an error status set.
: 
: There is no way to interrupt win32 syscalls...

other then not letting them block in the first place, and use asynchronous
versions instead, implementing an interruptable "block" in cygwin.dll.
If memory serves, NT calls that "overlapped I/O".
Or or there any NT calls for which this is impossible?

BTW, I also use alarm(60) and hope fgets()/write() on a socket return and
set errno to EINTR for timeout. So far, I haven't really tested under NT...


Bye, Heribert (dahms AT ifk20 DOT mach DOT uni-karlsruhe DOT de)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019