Hi, so Parrot will have (or already have) a frames for function calls allocated on stack or heap? I would like to implement a language which would allow many threads (millions) on Parrot, using similar design as found in Erlang VM (pool of OS threads which are giving time slices to stackless green threads). In case default Parrot settings would use stack, is there an option to change that and eventually plug-in specific GC which would not stop the world (having the threads isolated between each other)?
Karol On Mon, Aug 18, 2008 at 8:08 PM, Allison Randal <[EMAIL PROTECTED]> wrote: > Bob Rogers wrote: >> >> We're going to a completely stackless virtual machine. >> >> But Parrot is already stackless. The dynamic_env slot to which I assume >> you refer is really a tree with upward pointers. > > To be clear, Parrot will have no *global* stack. The data structure > implementing the stack isn't the problem, the global nature of it is. > >> And, how are you implementing those using 'pushaction'? >> >> Was [1] not detailed enough? This message links to [2] (from my YAPC >> talk), which has working examples (up until the merge at least). If you >> need more detail, please be specific, though it will probably have to >> wait until after the Parrot release. > > I need code examples. Show me samples of the PIR code you're generating that > used 'pushaction'. Try to include the smallest amount of code possible, so > we can go straight to "this is how I'm implementing feature X". > >> It sounds like you're trying to tell me that I should not be using >> continuations to implement *any* sort of nonlocal control flow. If so, >> it would have been kinder to say so before I put my time into a YAPC >> talk where that was the central theme. > > No, you should definitely use continuations. What you shouldn't use is the > dynamic_env stack. And, I'll happily walk you through moving away from the > dynamic_env stack and onto the new system. (I know it's different, which > causes initial frustration, but it's much better.) > >> They can effectively implement the same features as 'pushaction', but >> in a safer, continuation-friendly, non-global way. >> >> You've completely lost me. Not only do they have to be global (for some >> definition of "global"), as far as I was concernced they had been "safe" >> and "continuation-friendly" until the pdd25cx merge. > > No, it wasn't. The old code tied the continuation-based control flow to the > stack, requiring that the Continuation PMC's 'invoke' do all the work of > both a CPS virtual machine *and* a stack-based virtual machine. As a result, > we couldn't run continuations across the C barrier. As a result we were > getting numerous inexplicable segfaults and exceptions from obscure > control-flow bugs. Essentially, the old code was largely responsible for the > "inferior runloop" problem we've been tearing our hair out about for over a > year. It had to go. > >> At a minimum, I need to be able to return values. > > Yes, certainly. That's no problem. > >> But wait a minute: Aren't these features documented somewhere? If >> so, please point me there, and maybe I can figure out what I need on my >> own. If not, why not? > > The control actions? No. Because they're brand-new. Currently they're only > used by exceptions, but it sounds like Patrick will need them for Perl 6. > They will also be used by variants of local-branch and local-return that > don't accept a user-defined array object (but, those variants aren't > implemented yet). > > Allison >
