[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Catching Figure close button - callbacks not running?

From: Pavel Hofman
Subject: Re: Catching Figure close button - callbacks not running?
Date: Wed, 30 Jan 2019 13:00:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

Callback functions are written in m-code, as such they must be interpreted and are thus executed in the "interpreter" (or "worker") thread. The "main" (or "GUI")  thread is the one in which GUI objects (as figures) live.

Thanks for the explanation. I am slowly getting to understand octave details :-)

None of those make the interpreter idle: until "pause" or "zmq_poll" have returned, the interpreter is busy. The difference is that the "pause" explicitly calls process_events (only once in Octave 4.4, every 100ms in the soon released Octave 5) while I guess "zmq_poll" doesn't.

That explains why Tony's callbacks are processed (pause) while mine are not (zmq_poll with timeout).

If you want to obtain the same kind of behavior you could do something like

/havedata = false;/
/while (! havedata)/
/havedata/ *=* /zmq_poll (sock, 100);/
/  drawnow ();/

Thanks, I will explicitely call drawnow in the poll loop then.

I don't understand your use case, but anyway, as stated above, callback functions will always end up being executed in the "interpreter" (not "main") thread, where your program is executed.

IMO the important information (which I was not sure about) is "all code in one thread". Thanks for enlightenment.

Do you think it would be technically possible to run the callbacks in another thread using parallel package, allowing the callbacks to call pause() while the zmq_poll loop could cycle unaffected? It would require all the threads sharing/having access to global variables. I do not know if the parallel package allows this kind of computing.

Thanks a lot,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]