f-script-talk

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

[Jeremy S. <js...@ga...>]

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.

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

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

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..

First, pool := NSAutoreleasePool alloc init is similar to this Objective-C code:

    [aDictionary setObject:(NSAutoreleasePool alloc init) forKey:@"pool"]

When you bind the pool to the identifier p, the pool will receive a
retain message.  An autorelease pool will throw an exception if you
try to retain it.

You

here's what the release notes have to say:

"Note that you should not share workspaces or block environments
between multiple threads. If you need to execute multiple chunks of
F-Script code concurrently, you should use a different FSInterpreter
instance for each one."

If you detach a thread to a local block like that, you're sharing a
single workspace between multiple threads.  FScript isn't thread safe
in that way.

Also, pool := NSAutoreleasePool alloc init is similar to this Objective-C code:

    [aDictionary setObject:(NSAutoreleasePool alloc init) forKey:@"pool"]

When you bind the pool to the identifier p, the pool will receive a
retain message.  An autorelease pool will throw an exception if you
try to retain it.  You could work around this by using an NSValue
(wrappedPool := NSValue valueWithNonretainedObject:(NSAutoreleasePool
alloc init))

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