One question... you wrote:
So when
dealing with unknown objects whose thread safety is not documented,
you cannot access them from multiple threads without synchronization
just because they present an immutable interface.
When you talk about "accessing" these objects, do you also mean
reading ?
Because really all that my thread does is to read some values (i.e.
int imagewidth, int imageheight etc)
Then it generates NSImages that I alloc, init, output to disk and then
release....
I've put all the "UI" modifications (status text update etc) in a
separate method that I call using performOnMainThread:
As for the rest, granted the variables like imagewidth, imageheight
etc.. are SET by my UI (they are bound to controls in IB).. .but the
thread never actually modifies any variables/data shared with the main
thread... it only uses those variable to generate images...
I also released and re-created my pool after each image is generated...
Basically I get no errors/warning, everything seems to be working...
is it really though?? eh... I'm still not sure...
Jean-Nicolas Jolivet
On 19-Nov-08, at 5:24 PM, Michael Ash wrote:
On Wed, Nov 19, 2008 at 3:57 PM, Jean-Nicolas Jolivet
<[EMAIL PROTECTED]> wrote:
I have an app that generates a bunch of images... the process can
be long so
I wanted to start it in a separate thread so that the UI can be
responsive
etc...
basically the only thing I did was:
[NSThread detachNewThreadSelector:@selector(doLongProcess)
toTarget:self
withObject:nil];
and I added
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
at the beginning of my doLongProcess method, and [pool release] at
the
end...
Now the weird part is that... it appears to be working... the
images are
created...the UI stays responsive..my status textfield gets updated
(it
wasn't getting updated when the long process was not in a separate
thread)...
Am I wrong to think that it should've been much more complex than
that?
(With NSLocks and whatnot...) Maybe I should just shut up and be
happy that
it work, but somehow this doesn't seem right...
The basic principle of multithreaded programming is this: always
synchronize access to mutable shared data. In an environment like
Cocoa it becomes complex for a couple of reasons.
First, data can be shared not only within your code but with the
framework. This is why most of AppKit is not safe to call from
anywhere except the main thread. The framework has access to all those
tasty AppKit objects too, and the only way to synchronize access is to
make everybody use the same thread for it.
Second, when dealing with objects, "mutable" is very difficult to
discern. This "mutable" is not the same one as the one we look at when
we examine NSArray vs NSMutableArary. That mutable just means that the
contents of the NSArray don't change. The threading mutable means that
the *internal data structures* of the NSArray don't change. There are
all sorts of reasons why an immutable NSArray might still want to
change its internal data structures when things happen. So when
dealing with unknown objects whose thread safety is not documented,
you cannot access them from multiple threads without synchronization
just because they present an immutable interface. (As it happens,
NSArray *is* documented to be thread safe, but that was just an
example.)
So you got away without synchronization. How? Perhaps your shared data
truly was immutable, or documented as thread safe. If so, then you did
everything right. If not, then you may simply be getting lucky. One of
the painful things with threaded programming is that it's very easy to
do things incorrectly and still succeed... most of the time. Are you
also updating the text field from the thread? If so, that's
disastrously wrong, and you need to use performSelectorOnMainThread:
to manipulate any GUI objects, and it's working by luck.
Pure worker threads are generally pretty easy to do without a lot of
synchronization though, so what you're seeing isn't a big surprise. If
all you do is take a bunch of data and transform it into another bunch
of data, you can pretty much just pass that bunch of data off into a
worker thread, let it churn, and then get the result back when it's
finished.
Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/silvertab%40videotron.ca
This email sent to [EMAIL PROTECTED]
Jean-Nicolas Jolivet
[EMAIL PROTECTED]
http://www.silverscripting.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
