On Fri, Apr 30, 2004 at 01:54:58PM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> > 1: Right now, would it be possible for parrot only to install its signal
> > handlers when it starts the runloop?
> > (given that ponie isn't using the runloop)
>
> Currently Parrot installs just one handler (SIGHUP) for testing only.
> See src/events.c. So old issues WRT ponie regression tests should be
> solved.
And instead the perl regression tests that use SIGHUP fail.
(There are also tests on SIGUSR1, but not SIGUSR2, it seems)
> > IIRC parrot is currently assuming that we give it the address of a local
> > variable (for the stack top) before doing anything else, which is making
> > a big assumption about the calling locations of various parrot functions
> > within the code of the embedding program.
>
> The stack top has to be beyond any variables Parrot might see. When
> during DOD the stack (and the CPU registers) are traced all possible
> pointers to PMCs and Buffers must be covered by the range of the stack
> top and the current stack pointer.
>
> > ... Would it be possible for parrot to
> > provide an embedder's interface to all the (exported) functions that
> > checks whether the stack top pointer is set, and if not (ie NULL) it
> > pulls the address of a local variable in it
>
> This doesn't work:
>
> {
> PMC *x = pmc_new(..);
> {
> some_parrot_func();
> }
> }
>
> C<x> would be outside of the visible range of stack items. The braces do
> of course indicate stack frames.
This is true. And yes you need to set a stack top if you're expecting the
stack walking to find things you own. But I'm thinking about the case where
the embedding app registers all its PMCs immediately, and so doesn't expect
(or want) to be stack walked.
I doubt that ponie will be the only app wanting to take control of the
lifetime of all its PMC acting as references into the parrot VM
> see perldoc -F src/interpreter.c
Nice. Thanks
> > Also IIRC parrot is still creating globally visible symbols that aren't
> > well prefixed, so may cause linker fun. But that's not really a ponie
> > issue.
>
> Yep. A lot of. What's perl5 doing against those?
Prefixing all the linkable functions as Perl_ or PerlIO_ etc
(even if they are not part of the public API. Arguably we should be doing
something like PerlPrivate)
Global variables are prefixed PL_, which probably isn't long enough.
But for perl everything non-static has (or should have) a long prefix, to
make it unlikely that an external library will chance upon the same name.
Not perfect, but if someone else in the world calls their library Perl_
then it's their fault, not ours :-)
Or at least that's our story and we're sticking to it.
Nicholas Clark
