gnuplot-beta

Interrupts and communication with external gnuplot drivers

[<tim...@lp...>]

Dear all,

I am working on finalizing wxt running as a separate process so that it 
can work on MacOS. I am trying to figure out what's the best way to 
handle interrupts from the keyboard. First, I'd like to understand how 
gnuplot_x11 does it, but I don't get it:

gnuplot_x11 itself ignores interrupts
    gplt_x11.c, line4813
    signal(SIGINT, SIG_IGN);

gnuplot doesn't, but calls term->reset() and longjmp(). So communication 
with gnuplot_x11 (done with fprintf and fflush on one side, scanf on the 
other) can theoretically be interrupted, but in practice I just never 
saw any communication error. There isn't even a single check for 
returned values from fprintf and scanf. I have tried to hit ctrl-c while 
doing a long plot (something like "set samples 10000000; plot x") and 
never got any error.

Can someone explain this to me ?

Thank you very much.

Best regards,

Timothée Lecomte

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

Re: Interrupts and communication with external gnuplot drivers

[<tim...@lp...>]

Ethan A Merritt a écrit :
> On Saturday 22 December 2007 12:51, Timothée Lecomte wrote:
>   
>> Dear all,
>>
>> I am working on finalizing wxt running as a separate process so that it 
>> can work on MacOS. I am trying to figure out what's the best way to 
>> handle interrupts from the keyboard. First, I'd like to understand how 
>> gnuplot_x11 does it, but I don't get it:
>>
>> gnuplot_x11 itself ignores interrupts
>>     gplt_x11.c, line4813
>>     signal(SIGINT, SIG_IGN);
>>
>> gnuplot doesn't, but calls term->reset() and longjmp(). So communication 
>> with gnuplot_x11 (done with fprintf and fflush on one side, scanf on the 
>> other) can theoretically be interrupted, but in practice I just never 
>> saw any communication error. 
>>     
>
> I think I don't understand the question.  A normal user program will 
> 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.
>
>   
What I mean is the SIGINT signal generated by hitting ctrl-c on the 
keyboard, not all keyboard interrupts ;)

> (...)
>
>   
>> There isn't even a single check for  
>> returned values from fprintf and scanf. I have tried to hit ctrl-c while 
>> doing a long plot (something like "set samples 10000000; plot x") and 
>> never got any error.
>>
>> Can someone explain this to me ?
>>     
>
> I don't understand what error you were expecting. 
> Why would hitting ctrl-c be an error?
>
> 	Ethan
>   
When the user hits ctrl-c, the SIGINT handler is supposed to be run 
immediately, interrupting any operation running at that time. So I would 
have expected communication errors because fprintf()'s used in x11.trm 
can be interrupted before they finish, but I don't see any such error.

I hope it's clearer !

Best regards,

Timothée Lecomte

Re: Interrupts and communication with external gnuplot drivers

[<tim...@lp...>]

Ethan A Merritt a écrit :
> On Saturday 22 December 2007 13:41, Timothée Lecomte wrote:
>   
>> When the user hits ctrl-c, the SIGINT handler is supposed to be run 
>> immediately, interrupting any operation running at that time. So I would 
>> have expected communication errors because fprintf()'s used in x11.trm 
>> can be interrupted before they finish, but I don't see any such error.
>>     
>
> Two answers:
>
> Each write into the pipe from gnuplot to gnuplot_x11 is a unit.
> If you interrupt the process before it is sent, then nothing is sent.
> If you interrupt during/after it is sent, then so far as I know the
> entire write completes.  I don't think you can cause a partial write
> to a pipe by sending a signal to the task that does the writing.
>
>   
It's what my tests tend to prove, but nowhere in the docs it is said to 
behave that way. On the contrary, 'man 2 read' and 'man 2 write' 
explicitly say that a read or a write can be interrupted by a signal and 
then they won't have written or read all the bytes.

> You might be worried that the plot itself is incomplete, even though
> the individual write operations complete normally. But this doesn't matter.
> There is an explicit end-of-plot command sent over the pipe consisting
> of the single character 'E'. This is sent by X11_text().
> Until it receives that 'E', gnuplot_x11 just accummulates commands
> into a new plot structure.  If the 'E' is not received, then it will
> never try to display the plot. So it doesn't matter that it is incomplete.
>
> 	Ethan
>   
That part I don't understand too. In practice, when doing 'set samples 
10000; set isosamples 10000; splot x**2*y**2 with pm3d;' and 
interrupting the process with ctrl-c, I sometime got a partly rendered 
plot, whereas the 'E' obviously wasn't sent yet. I'm lost.

Best regards,

Timothée Lecomte