Front page | perl.perl5.porters |
Postings from November 2013
Re: Padlist NULL pointer?
From: Marc Lehmann
November 2, 2013 19:35
Re: Padlist NULL pointer?
Message ID: 20131102193532.GA4139@schmorp.de
On Wed, Oct 30, 2013 at 06:26:10PM -0000, Father Chrysostomos <firstname.lastname@example.org> wrote:
> Yes, even my supposed correction is faulty. :-(
> Another try:
That would only leak a few array entries (which is just a bit worse than
what was done before), however, on 5.18 and up, I guess I could just NULL
the highest pad ptr when I steal it, while leaving PadlistMAX alone?
That should not only work, but also not "leak" the extra space.
In any case, thansk to your input and pointers, I think I can fix it now.
[0 ptr where]
> pad.c:padlist_store, though it’s not obvious.
I see,t hat makes sense, thanks a lot!
> I have been thinking about this from time to time, but I have been
> hesitant, as I am not sure I understand exactly what is needed, and a
> badly-designed API is no better than no API if it is unusable due to
> its insufficiency.
> Do you have any suggestions for what such an API would look like?
There are currently two things where I somewhat wished Perl had direct
support for it.
First, coro_init_stacks i almost a complete copy of Perl_init_stacks
(including code style), the diference is that a) it's available to
extensions and b) it uses a lot smaller initial sizes (much like when
STRESS_REALLOC is used, although a bit more), as threads often don't need
much stack space, so you can have a lot more of them.
If perl had some kind of parameterisable version of Perl_init_stacks, I could
Second, the whole pad management. What coro needs is to be able to give a
function a fresh padlist (and free an existing one) - when coro switches
threads, it walks the callstack and saves the padlist of each function
that is in use (because the padlists store part of the call frame). It
then replaces the padlists of the functions used by the thread with the
padlists of the thread.
The fresh padlist is also cached in the CV.
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.
Now, Coro is very invasive, and (the thread core) only needed adjustments
twice, once for the return stack removal, and once for the new pad
The problem for me is really mostly that something needs to be done every
few months, which is why I more or less blindly applied your original
patch, something I rarely do :)
So, I don't think this is pressing. 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
I see that 5.18 finally has used up all the flags (and in 5.18, 0x4000
starts to collide with CVf_HASEVAL). I wonder if there is a flag that I
The flag collision isn't currently a problem, I think - coro sets this
on "schedule-like-functions", which are XS functions that potentially
switch threads, and it's only used as a consistency check (Coro patches
the op_ppaddr and uses this flag to detect when it is called on the wrong
CV, e.g. when it is called via goto or a reference, both of which are not
(I should have asked for this before 5.18 :)
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / email@example.com