Marc Lehmann wrote: > If perl had some kind of parameterisable version of Perl_init_stacks, I could > use that. Perl_init_stacks is an area I do not understand well. > So what coro needs would be a function that takes a cv as parameter and > returns an "empty" padlist. At the moment, this means it shares the names and > protopad, and as first pad of the "fresh" padlist, it uses the one generated > by pad_push. While that is certainly a bizarre usage for pad_push (and > probably broken in some corner case), it seems to work well in practise. As you wrote in a follow-up note: > it shares the names, and uses pad_push to create a new protopad. I don’t like the idea of adding a function that is so specific to Coro’s uses, that the core can’t use as well. I would suggest abstracting more of the underlying functionality: • newPADLIST(namespad) • Split pad_push into two functions, putting protopad-cloning in a separate function. > So, I don't think this is pressing. Phew. :-) I would like to solve the bless(sub{}) problem (bugs #3305 and #3306) by making anonymous sub clones share padlists (removing the overhead that is the reason for their not being cloned all the time currently), which might throw a wrench in the works. > However, if you want to do Coro some > good, there is somethign that I would really like: give me a CV flag: > > /* we hijack an hopefully unused CV flag for our purposes */ > #define CVf_SLF 0x4000 Bleadperl has this: typedef U32 cv_flags_t; In older perls, I think there is a 16-bit hole right after CvFLAGS.Thread Previous | Thread Next