Concurrent Truffle languages and creating threads

[Arthur Peters]

My main reason is fast thread locals, but it was also just convenient as
a way to bundle up all the state of the custom thread pool and worker
(I'm not using a Java ThreadPoolExecutor as the Java implementation is
too high overhead and has features I don't need). The convenience I can
work around, but the access to thread locals would be hard to replace,
because my language actually supports both a Truffle runtime and an
older interpreter backend. This means that many component (including the
thread pool and the standard library) cannot use the Truffle API since
they need to maintain compatibility with the legacy interpreter. We want
to maintain this compatibility to avoid needing to maintain two totally
separate projects (with our extremely limited research group). The
Truffle interpreter is not likely to replace the legacy interpreter for
a long time since the research focuses of the two runtimes are different.

I like Stefan's idea of just requiring an interface. This would allow
language implementation flexibility like my multiple backend problem.
Another option (as far as I am concerned at least) would be to extend
the Thread interface to return the Runnable passed to createThread. That
way people with odd needs (like myself) could extract a thread local
reference to our own "thread object" which could contain any thread
locals or support any other use cases that need a quickly accessable
thread local object for each thread.

-Arthur


On 09/29/2017 07:28 AM, Christian Humer wrote:
> Hi Arthur,
>  
> The reason to control the thread implementation is that we can do
> faster context thread-locals on the Truffle side and that we have a
> reliable way to run the Truffle prolog/epilogue. In the prologue, for
> example, we need to initialize the context thread local in order to
> allow languages to access their current context. There was a bug in
> previous versions of Truffle that allowed to access thread-local
> contexts from other manually created threads in certain brittle
> situations. So we just accidentally supported manually created threads
> in the past.
>  
> > Does this mean that my thread pool should use
> TruffleLanguage.Env.createThread?
>  
> Yes. TruffleLanguage.Env.createThread is intended to be used as a
> ThreadFactory.
>  
> > Or is createThread only required for specific cases?
>  
> Its almost always needed. As soon as you do any instrumentation, need
> to lookup your context statically or if you use interop with another
> language.
>  
> Could you elaborate a bit why you did decide to subclass your thread?
> For fast-thread locals?
> We plan to add Truffle fast-thread-local API, that allows every
> language to use fast thread locals independent of which language
> created the thread. Unfortunately this did not land in this release yet.
>  
>  
> - Christian Humer
>
>
> On Fri, Sep 29, 2017 at 12:23 AM Arthur Peters <amp at cs.utexas.edu
> <mailto:amp at cs.utexas.edu>> wrote:
>
>     I am implementing a language (Orc) which uses a thread pool for
>     execution (meaning any program running in this language will
>     always use
>     the thread pool). The change log for GraalVM 0.28 says that creating
>     threads using j.l.Thread is deprecated.
>
>     Does this mean that my thread pool should use
>     TruffleLanguage.Env.createThread?
>
>     Or is createThread only required for specific cases?
>
>     (Currently I use a Thread subclass for the worker threads in my thread
>     pool, so switching to createThread would require significant
>     refactoring.)
>
>     -Arthur
>
>