I’m writing a GUI that starts a worker thread using Thread.start. The
Cocoa docs say that you should update the GUI using the main thread
only. However, the examples that ship with Leopard, eg SimpleApp, have
a thread that update the GUI from the thread without passing it to the
main thread.
I would like to update a textview (with log info) and a progress bar
from the worker thread. At the moment the worker thread is updating
the log quite happily – it’s passed a closure from the controller and
calls log.call(msg).
Given that the examples and Cocoa docs seem to contradict each other,
what is the correct of doing this? I’d very much appreciate sample
code since I’ve just started using RubyCocoa (which is great!).
Since all Ruby 1.8 threads are within the same operating system thread,
so it’s usually safe to call GUI code in any thread.
A little bit of care can be needed, because ruby’s thread scheduler can
potentially switch context in a place where it shouldn’t. For example,
I’ve seen Carbon errors on OS X in wxRuby where it appears execution has
switched inside an operation like drawing to a device context.
I’m writing a GUI that starts a worker thread using Thread.start. The
Cocoa docs say that you should update the GUI using the main thread
only. However, the examples that ship with Leopard, eg SimpleApp, have
a thread that update the GUI from the thread without passing it to the
main thread.
When the Cocoa (Objective C) docs talk about threads, I would assume
they’re referring to operating system threads. Ruby 1.8 threads are not
operating system threads - they’re implemented within the interpreter.
Since all Ruby 1.8 threads are within the same operating system thread,
so it’s usually safe to call GUI code in any thread.
A little bit of care can be needed, because ruby’s thread scheduler can
potentially switch context in a place where it shouldn’t. For example,
I’ve seen Carbon errors on OS X in wxRuby where it appears execution has
switched inside an operation like drawing to a device context.
alex
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.