|
From: Dave D. <dde...@es...> - 2005-06-24 17:25:05
|
Timoth=E9e Lecomte <tim...@en...> writes: > Hello ! > > I keep working on the wxwidgets terminal, and I am now facing a > difficult problem. > > When there are errors on a command line, gnuplot uses its functions > int_error(token, string) to inform the user and stop parsing the > command line. This function prints an error message and then calls > bail_to_command_line() which is simply a wrapper for the standard > longjmp(env) function. This is similar to "goto", and puts the program > in its initial state by restoring the registers set in main(). > It is *currently* "simply a wrapper" for longjmp. A good while ago, I went through replacing lots of explicit longjmp calls with this wrapper, precisely so that the behaviour could be changed in a central way if it turned out to be necessary. > As far as I understand, this would be perfect if I had not to use a > separate thread for my terminal. Indeed, I want to send a command from > the terminal (through a menu for example) to gnuplot. I use events > defined in mouse.c, and more precisely a "command" event (which > doesn't seem to be used very often, or maybe in OS/2 only). The > do_event(event) is executed in my gui thread. When an error appears on > the command, we obtain a longjump which is invalid for *this* gui > thread... and it ends with a segmentation fault. > > I can't simply delete the longjump, as it is necessary to stop command > line parsing. If I do it, gnuplot either seems to enter in a infinite > loop or terminante with an other segfault. > Can't you just augment / replace bail_to_command_line() to make it do what you need ? Or you could save the existing jmpbuffer and do another setjmp to basically intercept the longjmp calls, letting you do any extra work, before you longjmp back to the original setjmp location. dd --=20 Dave Denholm <dde...@es...> http://www.esmertec= .com |