[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] Qt and Multithread
From:       Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date:       2005-10-19 14:57:11
Message-ID: 200510191657.12233.Richard_Dale () tipitina ! demon ! co ! uk
[Download RAW message or body]

On Tuesday 18 October 2005 23:52, Albert Cervera Areny wrote:
> Please take a look at http://doc.trolltech.com/3.3/threads.html as some
> concepts will also apply to Ruby. Most important for you will be the
> "Thread-safe Event Posting".
>
> Summarying, you have to run the main Qt loop with the same thread of your
> application. If you run another thread, you can't call GUI operations
> directly from the other thread. You need to postEvent() and reimplement
> customEvent() and make the GUI operations in there.
That works for C++, but the problem with ruby is that it doesn't use native 
threads like Qt/C++ (ruby threads are actually implemented via setjmp() and 
longjmp() calls). So even if you have multiple ruby threads, as far as the 
C++ Qt runtime is concerned there is still just one thread running. 

While control is in the top level Qt event loop, it will never be passed to a 
background ruby thread. Only when say a ruby slot is called in the main ruby 
thread, will a background ruby thread get a chance to run.

So this means that you can't use threads in QtRuby application, but it is less 
of a problem than it sounds. For instance, if you have a program which reads 
from a Qt::Socket, you can connect a slot to a signal indicating that there 
is something to read on the socket.

-- Richard
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]