On 13 July 2010 21:26, chromatic <[email protected]> wrote: > Whatever we do, we need to attempt to meet a few goals: > > * low CPU overhead for creating/managing concurrent entities of execution > (avoid the cost of creating a new Perl 5 interpreter, for example) > > * share as little as possible and that only explicitly (to avoid the C problem > of thread-unsafety by default) > > * allow options for parallelism and concurrency (to permit building something > like Python's GIL or Perl 5's ithreads without dictating too much) > > If possible, it'd be nice to avoid the problem that many dynamic languages run > into with C extensions, where wrapping a library that's not thread safe > dictates that the entire extension system needs a global lock. >
I know i am an outsider to this project but this is really interesting i'd love to see you follow the route of erlang, in one of my projects i follow python with gobal interpreter lock but i would have loved to see other ways of doing it and the potental pro's and cons! I found when implementing global interpreter lock in my runtime was painful at the start since it meant changes to some things to make them more reentrant, but its ok once you see where the problems arise mostly, and i had some problems with my garbage collector in that, i would sweep over all the memory, and it marks symbols and sticks them into a vector to be freed at once but it wasnt reentrant when garbage collection invokion would happen when poping out of procedure blocks which was really bad idea. I am just letting you know of some problems i had in one of my projects but whatever way you approach it, it would be great if you could make lots of noise about how you implement it on the parrot blog i'd love to read about it :) Keep up the awesome work --Phil _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
