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