Mail Archives: cygwin/1998/03/08/16:05:51
> if (signal(SIGALRM, handler) == SIG_ERR) return -1;
> alarm(5);
> printf("Set alarm. Getting input\n");
> ch = getchar();
[...]
> When this program is run on most Unix machines (OK, AIX needs kicking to
> get it to work), the getchar will return after the timeout occurs.
> What we see however is that after the timeout handler is called, the
> getchar does not return, it still waits for a character to be input.
Signals usually behave in one of two ways. Either they interrupt
a call and cause it to abort unfinished, or they interrupt a call
and cause it to be restarted. On most systems you can tell it which
of these two behaviors you want. Unfortantely under cygwin you can't
(as far as I know). The only behavior you get to use is the default
one: signal does not interrupt. (There are some exceptions - like
sleep()).
Ok, so how do you do the same thing if your signals don't behave
how you want? One way is to use setjmp:
handler() { siglongjmp(jbuf, 1); }
signal(...)
if(!sigsetjmp(jbuf, 1)) {
alarm(...)
getchar()
}
This will "warp" you out of the handler and back to the sigsetjmp
if the alarm goes off. Since signals can happen at almost any
time in cygwin, I don't know how safe this is. The program could
be running through cygwin "kernel" and grabbing temporary resources
and getting ready to give them back when a sigsetjmp causes a
"warp". I'm not sure if the kernel was designed with this in
mind.
A second approach you can take is to write your own getchar routine
with timeouts. You can do this using select() and setting them
timeout in select. If select returns on a timeout, dont bother
getting a character. If it selects for reading, then get a
character. Pretty simple.
> Ian Collins.
Tim N.
-
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 -