develooper Front page | perl.perl5.porters | Postings from November 2013

Re: Padlist NULL pointer?

Thread Previous | Thread Next
Father Chrysostomos
November 2, 2013 21:27
Re: Padlist NULL pointer?
Message ID:
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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About