[Octave-bug-tracker] [bug #44463] Print command for "pdflatexstandalone" device produces output that doesn't compile

[Pantxo Diribarne]

Follow-up Comment #12, bug #44463 (project octave):

Here is the structure of events ("->" means "calls methods of object") *in the
*interpreter thread*:
graphics_object->Backend(Implements base_graphics_toolkit for
Qt)->ObjectProxy

The latter then emits signals which are caught by corresponding Objects
(Figure, Toolbar, Menu, Panel ...) and lead to the *execution of the
corresponding slot in the GUI thread*. So ObjectProxy (last object in the
interpreter thread) returns well before the operation is completed.

The very nature of this structure of events makes sequential operation
impossible: we have no way to know if a slot execution has been completed
before going forward. The current approach of using mutex doesn't help much:
mutex are meant to make the execution of two functions (or part of) mutually
exclusive, but can't provide actual synchronization hence the ugly sleep I
added in drawnow. 

See the following very simple example:


## see bug for other such examples #46501
hf = figure ();
delete (hf)


Here we delete a figure graphics_object (that does exist because
graphics_objects are created in the interpreter thread) but we are not sure
the actual GUI figure window construction (in the GUI thread) is completed and
thus deleting the graphics_object is unsafe.

So my first statement is "we need to be able to force sequential operations".

Now the question is do we *always* want sequential operations: my answer ATM
is yes, there is *no benefit in having figures updated
independently/asynchronously from the interpreter state*. I can't see any
example of any operation that does not require synchronous interaction between
GUI and interpreter when it comes to plotting.

A possible approach could be to abandon the signal/slot mechanism in
ObjectProxy and use return values to ensure sequential operation. Of course
there may be more subtle solutions but I am no GUI expert.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44463>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/