[Octave-patch-tracker] [patch #7990] Add builtin Qt equivalents of UI dialogs, i.e., , qterrordlg, qtinputdlg, etc.

[Dan Sebald]

Follow-up Comment #25, patch #7990 (project octave):

I've tested the waitcondition behavior of the question dialog as described in
the diff file and script file attached to this post.  The test was to
repeatedly simulate a button press by passing in an extra variable to the
questdlg function that represents the index of the button that the main window
should click after creating the dialog.

I ran two tests, the difference being the following:

The first test checks that the mutex can be locked before awakening the worker
process.

  if (! mutex.tryLock (5000))
    {
      [snip error message]
    }
  else
    {
      mutex.unlock ();
      waitcondition.wakeAll ();
    }


The second test does not check for a lock, but simply awakes the worker
process.

   // Wake up Octave process so that it continues.
   waitcondition.wakeAll ();


Neither of these tests failed once in 1 million trials:


>> wctest
errors = 0
Elapsed time is 1e+04 seconds.



>> wctest
errors = 0
Elapsed time is 1e+04 seconds.


I'm surprised.  I was expecting the latter approach which does not check for a
lock to fail either by freezing or by getting the default result rather than
the button click result.

What I was trying to test with the above patch applies to this code on the
worker side of the signal/slot divide:


  uiwidget_creator.signal_dialog (QString::fromStdString (msg),
                                  QString::fromStdString (title),
                                  QString::fromStdString (dlg),
                                  QStringList (), QString (),
                                  QStringList ());

  // Wait while the user is responding to message box.
  uiwidget_creator.wait ();


Does it not seem that the thread could be interrupted between the signaling of
the dialog creation and going into the wait/sleep state?  That would leave
open the possibility that the GUI thread gets a little ahead of things and
awakes the worker thread before it has actually gone to sleep.  Apparently
that isn't the case though, but I can't explain why not.  I suppose it is a
good outcome, but maybe it is OS dependent or is just more rare than one in a
million.  Don't know.

So, what should we do here?  Go with what seems like the more robust approach
(i.e., check for a lock...I'll create a changeset).  Or try and explain why
there is no failure without checking for a lock?




(file #27953, file #27954)
    _______________________________________________________

Additional Item Attachment:

File name: octave-waitcondition_test-2013apr26.diff Size:11 KB
File name: wctest.m                       Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?7990>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/