Re: [F-Script-talk] NSThreads and F-Script

[Ken F. <ken...@gm...>]

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