Safe Asynchronous Functions (was: Re: std.concurrency: Returning from spawned function )

dsimcha dsimcha at yahoo.com
Sat Sep 11 07:03:06 PDT 2010


== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> That each spawn() results in the creation of a thread whose lifetime ends when
the function returns is an implementation details.

Fair enough.  I didn't realize this was just an implementation detail.  In this
case you're absolutely right.

> It could as easily be a thread pool that resets its TLS data when picking up a
new operation, user-space thread, etc.

I don't know the details of how TLS is implemented.  Would it be possible to reset
all TLS data for a given thread?  If so, I could make my std.parallelism module
that's currently in review (formerly parallelfuture for those who haven't been
following the Phobos list) support **safe** asynchronous function calls for a
limited but useful number of cases:

1.  Like for std.concurrency, all arguments must be free of unshared aliasing.

2.  The callable object must be a function pointer, not a delegate, template alias
parameter or object w/ overloaded opCall.

3.  If I could reset all TLS data in the worker thread upon returning, then I
could allow for arbitrarily complex object graphs as the return type, since the
worker thread could be guaranteed to not have any local references to the object
after the task returned.

This would probably be better than using std.concurrency for these cases because
even though asynchronous function calls look somewhat similar to message passing,
trying to use std.concurrency for such things is really shoehorning.
std.parallelism is actually designed for asynchronous function calls, but
currently has the disadvantage of being completely unsafe in that it allows
unchecked data sharing.

Also note that what I'm proposing would only be an additional feature for
std.parallelism, which would probably be called something like safeTask.  It would
still allow all the unchecked data sharing you could handle in @system mode.

>In short, I don't think that the behavior of a thread exiting should be a
motivating factor for design changes.  Does this gain anything over sending a
message on exit?

It allows safely passing an arbitrarily complex object graph because the fact that
the thread is exiting means you're moving it from one thread to another rather
than sharing it.



More information about the Digitalmars-d mailing list