Dan Sugalski <[EMAIL PROTECTED]> wrote:At 8:26 AM +0200 6/25/03, Leopold Toetsch wrote:
The first question is: Do we need such a limit check on the register backing stacks too?
If we're going to put limits in, yes.
If we want some secure executions modes too, we will need this anyway. The limit check in the 3 stacks I had put in is in the slow paths only. The same will work for the register stacks.
Works.
( /me again mumbling why we have 6 different stack implementations with a lot of duplicate code. One general stack with different sized data items would do it too - with some overhead ;-)
Well... we only really have three. The user and control stack are (or should be) the same, which is fine as they're single-element-with-pop-action stacks. The I/P/N/S stacks are all the same, the only reason they've got different code is because the elements are of different types and sizes. Macro-izing them would probably be in order, and the only real reason I didn't was that I was in too much of a hurry to do so. The integer stack's special-purpose, so that makes sense as well.
> I could've sworn that the stacks were taken piece by piece whenCOWed, but apparently not. They should be, though, as should the register stacks. No point in copying more data than we need to when we touch the things.
Yes, comments do state this. So we need general COWable buffers plus some rework in stack code.
Yep.
>>WRT coroutines: They have new_stack()s for Pad, User, and Control. Thelatter is probably wrong due to the planned exception mechanism. I presume that a coroutine works like a subroutine WRT exceptions, so that some parent can catch an exception that has originated in a coroutine.
Co-routines are going to have to be dealt with oddly, since their stacks need to reattach themselves to the caller's stack (at least the control stack) on every invocation. That is, the bottom of the coroutine's stack needs to attach to the top of the current stack every time the coroutine is invoked, which can be... fun.
This ought to be the same as not to have a separate control stack (as I mentioned above), but put a COWed copy of the callers control stack in place - at call time probably.
But calling a coroutine may involve putting the coroutine's stack in place as well, which is where the interesting bits come in.
> ... Especiallyif we need to deal with the possibility of multiple threads invoking the same coroutine, something that just occurred to me that I don't muck like the implications of.
I'm thinking of multithreading Parrot currently a lot and implications on some data structures. If you have any thouhgts floating around or even some finished bits please spit those out.
Some thoughts, but I keep redoing them. We can chat at YAPC::EU about it, I think.
-- Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
