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

Re: Padlist NULL pointer?

Thread Previous | Thread Next
From:
Marc Lehmann
Date:
November 8, 2013 08:23
Subject:
Re: Padlist NULL pointer?
Message ID:
20131108040259.GB3068@schmorp.de
On Sat, Nov 02, 2013 at 09:27:19PM -0000, Father Chrysostomos <sprout@cpan.org> wrote:
> Perl_init_stacks is an area I do not understand well.

It's just lots of mallocs, really.

> > 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.

That would work fine, would make it cleaner, and faster as well.

> > 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.

No problem, coro survived for a long term without any dedicated support
from perl.

> > 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;

Well, I'll be happy to get 0x10000 or any other value... It will only be
set on XS functions, and could probably be shared with any flag that is
never normally set on xs functions (with slight code changes in Coro to
tets for both flags).

The SLF means "schedule-like-function", it marks functions that can lead to a
thread switch (e.g. $semaphore->down or Coro::cede).

> In older perls, I think there is a 16-bit hole right after CvFLAGS.

So that leaves only 5.18 - older perls don't use 0x4000.  I guess a
tightening of the test might suffice in practise (CVf_HASEVAL is probably
not set together with CVf_ISXSUB).

In fact, Coro could probably continue to hijack CVf_HASEVAL in this case.
It's a hack, but probably not too ugly.

You could also add CVf_CUSTOM for use by extensions. That might increase
the chance of collision, but could be more generally useful as well.

All in all, I woudl prefer allocating a value until perl runs out of flag
space, if just for documentary purposes.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About