Front page | perl.perl5.porters |
Postings from November 2013
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