Re: Setjmp(), longjmp() in gnuplot

[<tim...@en...>]

Ethan Merritt wrote:

>Caveat: I don't really understand how your new terminal type is supposed
>to work.  So maybe I have the wrong end of the stick here...
>
>On Friday 24 June 2005 11:45 am, Timoth=C3=A9e Lecomte wrote:
> =20
>
>>As far as I understand, this would be perfect if I had not to use a=20
>>separate thread for my terminal. Indeed, I want to send a command from=20
>>the terminal (through a menu for example) to gnuplot. I use events=20
>>defined in mouse.c, and more precisely a "command" event (which doesn't=
=20
>>seem to be used very often, or maybe in OS/2 only). The do_event(event)=
=20
>>is executed in my gui thread. When an error appears on the command, we=20
>>obtain a longjump which is invalid for *this* gui thread... and it ends=
=20
>>with a segmentation fault.
>>   =20
>>
>
>I would think the proper fix is to re-initialize the longjump at the
>start of each thread creation.  Then if you get an error it will jump
>to a per-thread error handler and exit the thread cleanly.
> =20
>
I have just tried it. The remaining problem is that setjmp/longjmp were=20
designed for C, not C++. In particular, longjmp doesn't do any extra=20
work needed by C++, such as deleting objects. So if I initialize the=20
longjump when creating my terminal thread, it doesn't delete the old=20
window but open a new one when longjmp is used ! However, it does not=20
segfault... So the solution may be to check if another window is opened=20
and destroy it before to continue. That doesn't seem very efficient.

>>Another solution would be to build the terminal as a separate process,=20
>>like x11 or os/2 ones. But I think it's not an optimal design.
>>So I would be pleased if somebody can give me a tip in order to deal=20
>>with this issue ;-) .
>>   =20
>>
>
>I might understand better if you would briefly describe the flow of
>control you are trying to achieve.  What does the new terminal type do
>that existing terminals do not handle already?  Is the user expected to =
run
>gnuplot from a command line, but when 'set term wxwidgets' is selected a=
=20
>separate control window appears?   Or does the user run a wrapping progr=
am
>that executes gnuplot underneath with the terminal pre-set to communicat=
e with
>the wrapping layer? =20
>
>If it's the latter, then I'm not sure you even  need a new terminal type.
>You may be able to use 'set term x11' and direct the output to an embedd=
ed
>panel of the wrapping program (see patchset #1027032).  I'm not saying t=
his
>is the best thing to do, but I point it out as a possibility.
> =20
>
I will try to explain briefly.
I write a terminal like the x11, postscript, etc. So I use the standard=20
gnuplot interactive command line, type "set terminal wxt" and then any=20
plot command makes the plot window appears, as the x11 terminal works=20
for example. The window is opened in a thread inside gnuplot main=20
process. Thus, your precedent remark is pertinent.
I want to implement extra interactivity menus or toolbar. So I want to=20
send commands back to the command interpreter. I do that with do_event=20
which is precisely written for it.

Regards
Timoth=C3=A9e