[Kde-bindings] QThread through smoke?

[Richard Dale]

On Saturday 12 February 2005 13:10, Caleb Tennis wrote:
> On Saturday 12 February 2005 03:08, Richard Dale wrote:
> > Ruby threads aren't native threads, and are different to Qt threads. I'm
> > not sure that it's a good idea to use Qt::Threads with ruby - why not use
> > ruby threads? All Qt calls need to be made by the main thread, but as
> > long as the other threads don't make Qt calls it works fine.
>
> The main reason I started playing with it is that Ruby subthreads seem to
> handle blocking IO differently than the main thread, which is a bit of a
> pain when you're doing serial IO in a subthread.  I have a multithreaded Qt
> program that runs very well, but my attempts to rewrite it in RubyQt aren't
> going so well due to the fact that the helper threads block for longer
> periods of time and slow the GUI thread down.  I was hoping that using a
> native QThread would help, but it was just experimental.
I see - Qt::Thread could be added to the Smoke lib - it should do a 
configuration check to see if qt was built with the -thread option though, 
rather than hard wire it into kalyptus.

But maybe it would be better to look into why ruby blocks. Have you tried 
something like 'mystream.sync = true'? Or have you got a small sample of code 
that reproduces the problem - it's difficult to know what it could be without 
seeing it and trying it out.

Does it need multithreading - could you do something with Qt::SocketNotifiers 
for input and output connected to slots to read and write, and let Qt 
coordinate the app in that way?

-- Richard