Concurrent Truffle languages and creating threads

[Christian Humer]

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