Concurrent Truffle languages and creating threads

[Stefan Marr]

Hi:

Hm, this looks again totally closed and impossible to extend:

https://github.com/graalvm/graal/blob/727cc29f9747d93a0c8fc1f1384c05731658fa7a/truffle/src/com.oracle.truffle.api.vm/src/com/oracle/truffle/api/vm/PolyglotThread.java

How do I implement fast thread locals with this design?

I need them for various things from implementing my actor system, over tracing (needs to be really low overhead), to debugging.

On first sight, this looks again like one of those design decisions that will prevent people like me to do anything cool/researchy and have fun while doing it.

Any suggestions appreciated.

Thanks
Stefan


> On 29 Sep 2017, at 11:02, Boris Spasojevic <boris.spasojevic at oracle.com> wrote:
> 
> Hey Arthur,
> 
> Not sure about the details of your use case, but AFAIK subclassing Thread should be avoided in Java, so maybe investing in the refactoring might be worth while.
> 
> When you say that you use a thread pool, do you mean you use a ThreadPoolExecutor? If so, I guess you could use a ThreadFactory to it which wraps TruffleLanguage.Env.createThread.
> 
> Cheers,
> BoriS
> 
> 
> On 09/28/2017 05:48 PM, Arthur Peters 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
>> 
>> 
> 

-- 
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/