Re: Race condition seems to be fixed

[Jacob Dawid]

John,

I don't know whether I found the best place for the callback, but practically it seems to work fine, very responsive and without any performance loss. I wouldn't spend to much time on thinking about problems that we don't have to face (yet). We can still decide about the position of the callback in the future, the GUI does not care about that, since updating the model (which is what the callback does) is decoupled thread-safely from the GUI anyways.

As for the name: We can change that also, but I didn't find a better one. Maybe "octave_loop_hook" or something similar? However, I created a patch for default and attached it to this mail. After merging default into gui I should be able to fix the GUI so it does not crash anymore.

Best regards,

Jacob

2012/5/21 John W. Eaton <address@hidden>

On 21-May-2012, Jacob Dawid wrote:

| Hello maintainers,
|
| I probably fixed the race condition a few minutes ago. What I did was to
| separate the workspace model from the view as a prerequisite in the GUI, then I
| added an octave_loop callback into octave's main_loop(), in the same way the
| octave_exit callback was added. Usually, this callback is null, so it won't be
| called when there hasn't been set a callback. I did a hg diff (I hade to modify
| toplev.h and toplev.cc) attached to this mail and kindly ask for confirmation
| that I can push this on the GUI branch, see the very bottom of this file.

Please propose the change to the default branch as a patch separate
from any changes on gui branch.

 diff -r 664f54233c98 src/toplev.cc
 --- a/src/toplev.cc   Sun May 20 22:05:49 2012 +0200
 +++ b/src/toplev.cc   Mon May 21 01:20:34 2012 +0200
 @@ -77,6 +77,7 @@
  #include "variables.h"
  #include "version.h"

 +void (*octave_loop) () = 0;
  void (*octave_exit) (int) = ::exit;

I think we need better names for these function pointers.

  // TRUE means the quit() call is allowed.
 @@ -560,6 +561,9 @@
      {
        try
          {
 +       if (octave_loop)
 +         (*octave_loop) ();
 +
            unwind_protect frame;

            reset_error_handler ();

I'm not sure this is the best place for the callback.  Should it also
be called when Octave is waiting for input?  What about when it is
evaluating a statement passed to the eval function?  Or when Octave is
doing debugging and evaluating expressions at the debug> prompt?

jwe

patch.diff
Description: Binary data