Re: Interrupts and communication with external gnuplot drivers

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 22 December 2007 12:51, Timoth=E9e Lecomte wrote:
> Dear all,
>=20
> I am working on finalizing wxt running as a separate process so that it=20
> can work on MacOS. I am trying to figure out what's the best way to=20
> handle interrupts from the keyboard. First, I'd like to understand how=20
> gnuplot_x11 does it, but I don't get it:
>=20
> gnuplot_x11 itself ignores interrupts
>     gplt_x11.c, line4813
>     signal(SIGINT, SIG_IGN);
>=20
> gnuplot doesn't, but calls term->reset() and longjmp(). So communication=
=20
> with gnuplot_x11 (done with fprintf and fflush on one side, scanf on the=
=20
> other) can theoretically be interrupted, but in practice I just never=20
> saw any communication error.=20

I think I don't understand the question.  A normal user program will=20
never see keyboard interrupts (meaning "interrupt generated by pressing
a key on the keyboard").  This is all handled in the kernel as part of
filling an I/O request.  The user program only sees completion of the
I/O request.

signal (SIGINT, SIG_IGN)  refers specifically to the SIGINT signal.
This has nothing in particular to do with the keyboard, except insofar
as one way of generating a SIGINT signal is to type <control-C> or
<escape> or whatever convention you have your current terminal interface
set to.  Another way to generate a SIGINT signal is "kill -INT <pid>"

Does that help?

> There isn't even a single check for =20
> returned values from fprintf and scanf. I have tried to hit ctrl-c while=
=20
> doing a long plot (something like "set samples 10000000; plot x") and=20
> never got any error.
>=20
> Can someone explain this to me ?

I don't understand what error you were expecting.=20
Why would hitting ctrl-c be an error?

	Ethan

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742