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.
> 2: Long term can parrot interwork nicely with existing signal handlers
> by storing the function pointer returned by signal() when it installs
> its handler, and calling that function when its signal handler is called?
Shouldn't be too hard, yes.
> IIRC ponie isn't playing nicely with how parrot does embedding. I'd like
> parrot's embedding to be as "clean" as perl's.
A lot of interface functions are still missing.
> 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.
> IIRC there only interface to call into parrot bytecode subs currently
No. There is a lot:
void Parrot_runops_fromc(Parrot_Interp, PMC *sub);
void Parrot_runops_fromc_save(Parrot_Interp, PMC *sub);
void* Parrot_runops_fromc_args(Parrot_Interp, PMC *sub, const char *sig, ...);
void* Parrot_runops_fromc_args_save(Parrot_Interp, PMC *, const char *, ...);
INTVAL Parrot_runops_fromc_args_save_reti(Parrot_Interp, PMC *,
const char *, ...);
FLOATVAL Parrot_runops_fromc_args_save_retf(Parrot_Interp, PMC *,
const char *, ...);
plus a bunch more to run method functions.
see perldoc -F src/interpreter.c
> ... Can the NCI code work for calling into parrot,
> as well as calling out?
NCI calls C functions from byte code. Calling PASM/PIR from C is done
with above functions. And there is PASM->C->PASM via callback functions.
> 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?
> Sorry if I'm behind the times on parrot, and some of what I remember is
> wrong.
No problem.
> Nicholas Clark
leo
