[LLVMdev] Erlang
Álvaro Castro Castilla
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.
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Bill Wendling
Your question is too vague to answer with any accuracy. Could you be
more specific?
-bw
On Jul 24, 2008, at 1:08 PM, "Álvaro Castro Castilla" <alvaro.cast...@gmail.co
Álvaro Castro Castilla
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.
2008/7/24 Bill Wendling <isan...@gmail.com>:
--
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> http://www.alvarocastro.es
Owen Anderson
> 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
Simon Ask Ulsnes
>> * 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.
- Simon
Álvaro Castro Castilla
> 2008/7/24 Owen Anderson <resi...@mac.com>:
>>> * 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.
> - Simon
> _______________________________________________
> LLVM Developers mailing list
> LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
--
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> http://www.alvarocastro.es
John Regehr
> 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
Jonathan S. Shapiro
> 2008/7/24 Owen Anderson <resi...@mac.com>:
> >> * 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
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
Torvald Riegel
> 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.
Hi,
do you have pointers to more informations about this, or could you elaborate?
Thanks.
Torvald