octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #55225] building doc figures in .eps or .pdf f


From: Pantxo Diribarne
Subject: [Octave-bug-tracker] [bug #55225] building doc figures in .eps or .pdf format occasionally silently fails
Date: Tue, 2 Jun 2020 18:29:56 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Follow-up Comment #56, bug #55225 (project octave):

>> Is there any chance that using this method can cause a deadlock?

The only way I know of to provoke a deadlock is if we block the interpreter
thread while it owns the graphics mutex, and we try to lock the mutex from the
GUI thread. 

We should thus make sure, prior to executing methods in the GUI thread, that
the interpreter thread does not own the graphics mutex:

* In qt_graphics_toolkit::initialize and qt_graphics_toolkit::finalize we have
this construct:


    // FIXME: We need to unlock the mutex here but we have no way to know if
    // if it was previously locked by this thread, and thus if we should
    // re-lock it.

    gh_manager& gh_mgr = m_interpreter.get_gh_manager ();

    gh_mgr.unlock ();
    
    ...


* As for qt_graphics_toolkit::print_figure, it is currently only called from
Fdrawnow after explicitly unlocking the graphics mutex.


          gh_mgr.unlock ();

          go.get_toolkit ().print_figure (go, term, file, debug_file);

          gh_mgr.lock ();


* And finally qt_graphics_toolkit::get_pixels: it is currently only called
from F__get_pixels__ which doesn't lock the mutex.

We need to harmonize this all. 

I think it would be easier to avoid the construct from Fdrawnow, where the
caller has to know that qt_graphics_toolkit::xxx_method needs to be executed
while the mutex is unlocked. Instead, the caller should just expect
qt_graphics_toolkit::xxx_method to do its job and return with the state of the
mutex unchanged.

The problem (see FIXME note in above code) is that the gh_manager does not
seem to provide a way to know if the mutex is currently locked by this
(interpreter) thread. 

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55225>

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




reply via email to

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