Re: [F-Script-talk] NSThreads and F-Script
Brought to you by:
pmougin
From: Ken F. <ken...@gm...> - 2006-09-09 22:49:17
|
On 9/9/06, Ken Ferry <ken...@gm...> wrote: > On 9/8/06, Jeremy Sacket <js...@ga...> wrote: > > > > Is it possible > > use (void)detachNewThreadSelector:(SEL)aSelector > > toTarget:(id)aTarget withObject:(id)anArgument > > inside a block and call another block that is defined. > > > > I.E something like... > > > > Thread:=[ > > Do this in another tread."" > > pool := ((NSAutoreleasePool alloc) init). > > ...... > > [pool release]. > > > > ]. > > > > NSThread detachNewThreadSelector:#thread toTarget:self > > withObject:null. > > > > Not quite like that.. [snip] Oops, didn't mean to send that! I don't think you can do this without an objective-c helper today. When a block receives the value message, F-Script's runtime retains and autoreleases the block. If you do NSThread NSThread detachNewThreadSelector:#value: toTarget:block withObject:nil there will be no pool in place to catch the autorelease message sent to the block. Anyway, the more interesting part is the thread safety of executing a block. The release notes say that you cannot "share workspaces or block environments between multiple threads". From looking at the code, and experimentally, it looks like it may be enough if a block uses only local variables. Philippe would have to say if that's guaranteed, though. I think Philippe is on vacation for a little while. If that isn't enough: A block that you create with -[NSString asBlock] has its own top-level workspace. If you archive and unarchive a block, that should also separate it from the current workspace. A high level way to do that would be to use distributed objects, for which F-Script has some explicit support. Again, I don't know what Philippe would recommend. Sorry for the partial information! -Ken |