Re: Passing variables up to the GUI

[Daniel J Sebald]

On 04/14/2013 05:17 PM, Michael Goffioul wrote:
> A QThread is a plaform-independent wrapper on top of a OS thread. When
> you emit a signal whose receiver is in another thread, Qt will copy the
> argument of the signal (invoking copy-constructor) and stashed the
> signal in the event queue of the received thread. When the OS switches
> thread context and make the target thread to continue execution, the
> eventloop of the receiver thread will pick up the event and execute the
> slot. But the source thread continues execution. Theoretically, 3) and
> 5) can be executed concurrently by the linux/Windows/mach/whatever kernel.
>
> We can stop the discussion here and agree to disagree. But I believe
> that passing octave_value objects across threads (through Qt signal/slot
> or whatever else mechanism) can lead to unpredictable results due to the
> non-thread-safe nature of refcount management. Once that problem is
> solved, then I fully agree that all your suggestions make sense: that
> is, Qt will hold a reference to the passed object until the slot
> execution is completed, and the emitter can safely discard its own
> reference.

OK, I've located the Qt core code and see how queued signals are 
created.  It looks like a copy is made for each slot connection.  I see 
how the events are placed in the queue for the other thread.  The meta 
stuff is complex enough to see that exactly figuring out what is going 
on probably isn't worth it.  There is some kind of deferred delete kind 
of thing and a deleteLater, but I think that is only for objects.  So, 
I'm thinking you are right about thread safety here.  Sorry if I've 
discovered what you've already have, but hey the signal/slot thing is 
like magic.

QObjects have some protection and so on and I've wondered if that can be 
utilized, but that too is getting complex.  Neither is it general.

I have an idea in mind, but it would require putting the Octave process 
to sleep momentarily (and maybe ultimately that is always going to be 
the case with a GUI and attempting to see the data).  If the rep-count 
construct/destruct could be altered slightly so that if the rep-count is 
-1, the value of rep-count is not altered by the constructor/destructor, 
then we could do something like this:

octave_value_list result = eval_string(...,nout)
if (OK)
  for i=0; i< nout; i++
  {
    copy_count(i) = result(i).rep.count;
    result(i).rep.count = -1;
  }
  emit command_result (result)

  put_thread_to_sleep()

  //Restore the count
  for i=0; i< nout; i++
  {
    result(i).rep.count = copy_count(i);
  }

That way none of the copy/deletes going on in the signal/slot mechanism 
will have any effect on the rep-count.  In the GUI thread would be:

octave-link::handle_command_result (QObject *ID, octave_value_list& result)
{
  // Transmit result to other objects in GUI.
  emit have_command_result (ID, result);

  // No longer need this data
  wake_up_the_worker_thread()
}

Dan