On Thu, 21 Aug 2003, Tom Locke wrote:
> > > My big requirement is for lightweight microthreads...
> >
> > Parrot's going to live on top of the system thread library, so you may run
> > into some issues that way. Not all systems can handle lots of
> > threads--many of them (including Linux) have very low limits relative to
> > what most microthread-based systems expect.
>
> But Parrot has continuations. Doesn't this gives me (cooperative)
> microthreads? (with a little work on my part).
Sure. And with a little work you could have one parrot interpreter per
microthread, have a zillion (well, memory permitting as the interpreters
are a bit porky) interpreters and switch between them yourself.
You could also play interesting games with the event system and a timer,
now that I think about it.
> > I'm still not 100% sure about serializable continuations, though I expect
> > so.
>
> Weather or not I go for Parrot, I would very much encourage you in this
> direction. The world needs:
>
> * Long lived processes (long could mean years!)
> * ACID transactional processes
> * Mobile processes
The world could also use a pony. And a lollypop. :) Seriously, while I'd
want to, whether it happens depends on a number of engineering and
personnel factors--while nice, it's not as important as other things.
> > (They may be rather large when serialized, though)
>
> With a deep stack, this is inevitable right? Or are you saying that Parrot
> would be worse than other systems in this respect?
Probably worse, since to serialize a continuation properly means
serializing everything the continuation would need to reconstitute itself,
including any and all code it has a handle on, lexical pads, used global
variables, and so forth. I'd bet about 90% of what an interpreter had
loaded would need serializing in the conservative case.
Dan
