Erlang

Hello,

How would you implement an Erlang feature such as the ultra-light processes?
Is llvm prepared for similar situations?

I would appreciate some insight on this.

Thank you very much,

.alvaro.castro.castilla.

Hi Álvaro,

Your question is too vague to answer with any accuracy. Could you be more specific?

-bw

Hi,

Sorry for the vagueness.

I'm starting to think about an experimental programming language
based, among other things, on microthreads, or green threads, as
Erlang has. I'm still under a very vague stage, just thinking on it,
so I was wondering on the way this could be achieved.

What I know from microthreads are things like:

* They don't have their own stack
* Switching between threads is controlled by the application, not the OS
* They are isolated and the only way to exchange information is message passing

Erlang requires an interpreter for this, but, how could I achieve a
similar feature for my language with the LLVM JIT?

I hope this is a bit clearer,

Thank you!

.alvaro.castro.

Hi,

Sorry for the vagueness.

I'm starting to think about an experimental programming language
based, among other things, on microthreads, or green threads, as
Erlang has. I'm still under a very vague stage, just thinking on it,
so I was wondering on the way this could be achieved.

What I know from microthreads are things like:

* They don't have their own stack
* Switching between threads is controlled by the application, not the OS

These two can be done in C pretty easily. Try googling for "protothreads" for a library that implements this. To see how it looks in LLVM, compile it down to bitcode and take a look.

* They are isolated and the only way to exchange information is message passing

This one is hard to guarantee in a compiled context, unless you implement a lot of stuff to track pointer values. Remember, all of these threads will be sharing an address space. If you want true protection, you'll want something more like fork(), but that defeats your other two goals.

--Owen

Couldn't this also be semi-guaranteed by the design of the language?
For instance, if you completely disallow pointer arithmetics and
always pass by value when passing messages. Could probably be quite a
bit of copying, but if the guarantee is important, I'm guessing this
is cheaper than tracking all pointers. I could easily be completely
wrong.

- Simon

* They are isolated and the only way to exchange information is
message passing

This one is hard to guarantee in a compiled context, unless you
implement a lot of stuff to track pointer values. Remember, all of
these threads will be sharing an address space. If you want true
protection, you'll want something more like fork(), but that defeats
your other two goals.

Couldn't this also be semi-guaranteed by the design of the language?
For instance, if you completely disallow pointer arithmetics and
always pass by value when passing messages. Could probably be quite a
bit of copying, but if the guarantee is important, I'm guessing this
is cheaper than tracking all pointers. I could easily be completely
wrong.

I'll investigate on how that is achieved in Erlang, so I can ask more
precise questions.

I knew protothreads, but I still have to figure out the limitations
resulting from the fact that local variables are not preserved when
the protothread blocks. Is protothreads library able to keep a bunch
of living threads during program's life that exchange data through
message passing?

Thanks for your suggestions,

.alvaro.castro.

I knew protothreads, but I still have to figure out the limitations
resulting from the fact that local variables are not preserved when
the protothread blocks. Is protothreads library able to keep a bunch
of living threads during program's life that exchange data through
message passing?

I would recommend against stackless threads. If you really can't afford a few KB per stack, go with an event-driven execution model where events run to completion.

John

This is excessively conservative. Any state that is deeply
"pure" (therefore constant) *can* be shared, and at least some type
systems are strong enough to tell you this. This potentially includes a
lot of internal representation data, which significantly alters the
performance trade-offs here.

It is also possible to bring linear typing into messaging, as
Singularity did. Where that works, no copy is required. That said, the
singularity design is open to resource denial of service on the heap
because they didn't get the pragmatic details of linear-typed messaging
quite right.

shap

Hi,

do you have pointers to more informations about this, or could you elaborate?
Thanks.

Torvald