Concurrent Truffle languages and creating threads

[Christian Humer]

Stefan,

> Are you going to provide and maintain a Truffle-lized Fork/Join pool as
well?

I did not think about this. Do you actually use it? If not, then we can
think about it when we need it. You can still use Java Fork Join using Java
interop, this limitation only applies to Truffle language implementations.

> You’re going to rely on having a context field in each thread?

For every thread except integrator threads. We want to allow fast thread
and context local data for all languages independent of the language that
created it. That API did not land yet.

> Can’t we just have an interface or so for that?

Maybe. We need to ensure that context handling remains an implementation
detail.


Cheers,
Christian


On Fri, Sep 29, 2017 at 12:54 PM Stefan Marr <java at stefan-marr.de> wrote:

> Hi Chris:
>
> > On 29 Sep 2017, at 11:43, Chris Seaton <chris.seaton at oracle.com> wrote:
> >
> > How did you implement fast thread locals with the previous design?
>
> By using fields on subclasses of Thread.
>
> Indirectly actually:
>
>
> https://github.com/smarr/SOMns/blob/master/src/tools/concurrency/TracingActivityThread.java#L16
>
> https://github.com/smarr/SOMns/blob/master/src/som/interpreter/actors/Actor.java#L328
>
> And thinking about it.
> You are effectively telling me also that I can’t use Java’s Fork/Join pool
> anymore.
> It also relies on a subclass of Thread.
>
> Are you going to provide and maintain a Truffle-lized Fork/Join pool as
> well?
>
> Or asked differently:
> What is going to happen if I do just continue to use my own threads?
> What am I going to lose?
>
> You’re going to rely on having a context field in each thread?
>
> Can’t we just have an interface or so for that?
> This seems all highly problematic. :(
>
> Thanks
> Stefan
>
> --
> Stefan Marr
> School of Computing, University of Kent
> http://stefan-marr.de/research/
>
>
>