Re: Multiple Threaded Windows
Re: Multiple Threaded Windows
- Subject: Re: Multiple Threaded Windows
- From: Eric Dahlman <email@hidden>
- Date: Fri, 10 Oct 2003 10:10:01 -0500
On Friday, October 10, 2003, at 08:55 AM, Chris Scharver wrote:
On Tuesday, October 7, 2003, at 02:08 PM, Chris Hanson wrote:
According to that document, more of AppKit is thread-safe than I
thought it was (and much more than used to be -- especially in the
OpenStep days when I first learned it). But I'm still *extremely*
wary of dealing with human interfaces in multiple threads.
Unfortunately, both the developer documentation and mailing list
archives don't go into much beyond paragraphs mentioned by others.
I've read the same paragraphs, but there is very little describing how
to actually do something. Because I'm using existing code which works
with X11 and Win32, I cannot radically alter the library's design. My
goal is to determine how I can fit Cocoa into this design (if at all!)
Thus far, the results haven't been very encouraging, but there's
probably a lot that I'm not correctly taking into consideration.
Does this application work on a vanilla X11 setup? If so you may be
much closer than you think because unless you are using a specially
compiled thread safe version of xlib (which is not the default) then
the situation exactly parallels that in Cocoa. Only one thread can
make xlib calls at a given time and to simplify life most sane
designers use something like a designated GUI thread for that purpose.
Also, threads are flows of execution. Objects do not "live" in any
particular thread, they live in a task (address space). So just
because one thread created an object does not mean that object
"belongs" to the thread.
I meant only to indicate that the windows and views are created in the
threads, and therefore functions called from main to do not directly
access any of those objects. Some platforms running this code use
fork() rather than threads, so those semantics are still kept in place
whether using multiple threads or multiple processes. With the
library's other windowing environments, drawing surfaces live safely
on the child threads without interference from the main process.
Trying to discover the required steps to implement similar behavior
using Cocoa is a challenge. I may just have to stick to X11 or forgo
drawing to multiple windows.
One thing to keep in mind is that you can change the model part of a
MVC design in another thread to your hearts content so long as you do
enough synchronization so that when the main thread renders it things
are consistent. In some cases this synchronization may well be a no-op
like where you are updating a matrix of values and if half the matrix
is from one iteration and the other from the next you don't care. This
would look like tearing in an animation but it may well be acceptable
for what you are doing it really is a question of whether the frame
rate is high enough to make things not matter.
-Eric
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.