I've posted an update/resolution reg this issue to perl5-porters. FYI
http://markmail.org/message/cjbhybjfikuirvud
--- On Wed, 11/4/09, Sri <w2le...@yahoo.com> wrote:
> From: Sri <w2le...@yahoo.com>
> Subject: Using multiple perl interpreters
> To: modperl@perl.apache.org
> Date: Wednesday, November 4, 2009, 8:49 PM
> Hi,
>
> I've read several posts on this forum on similar topic, but
> not able to figure out the problem in my specific case. So
> hoping someone can help me here. Essentially, its a
> seg fault when using a thread-specific interpreter.
>
> I'm trying to provide a Perl interface to a C library
> (event-driven). The C library has APIs, ofcourse, but
> it also allows perl-subroutines to be registered as
> callbacks into the C library. The C library has a
> thread that monitors external events and invokes the
> perl-sub callbacks.
>
> The default perl interpreter is executing the script
> (interpreter instance one). I do NOT have any code to
> create/initiaze this instance in my api
> wrappers. My library's thread, creates a
> new interpreter. But, crashes in the call_sv().
> If I execute the same code (call_handler below, unmodified)
> as part of an API call invoked from perl-script, it works
> just fine. So, I feel I'm not initializing/using the
> 2nd instance correctly or "coordinating" between the two
> instances properly. If anyone has pointers or other
> forums that may specialize in this topic, it would be great
> help.
>
> I tried to use perl_clone instead of perl_alloc, but that
> method crashed too.
>
> ---using perl 5.8.8, compiled with multiplicity, implicit
> context (see below)---
>
> void mythread_fn(void)
> {
>
> static
> PerlInterpreter *my_perl=NULL;
>
> my_perl =
> perl_alloc();
>
> PERL_SET_CONTEXT(my_perl);
>
> perl_construct(my_perl);
> perl_run(my_perl);
>
> while (1)
> {
>
> /*
> monitor for events */
> if
> (event == xyz)
>
> callback_handler(event);
> }
>
> perl_destruct(my_perl);
> perl_free(my_perl);
> }
>
> void callback_handler(int event)
> {
> dTHX;
> dSP;
>
> ENTER;
> SAVETMPS;
>
> SV * sv = disc_callback; /*
> saved earlier in an API call */
> if (sv == (SV*)NULL)
> croak("Internal
> error...\n");
>
> PUSHMARK(SP);
> XPUSHs(sv_2mortal(newSViv(event)));
> PUTBACK;
>
> /* Call the Perl sub */
> call_sv(sv, G_DISCARD); /*
> crashes as shown below in gdb */
>
> FREETMPS;
> LEAVE;
> }
>
> Part of gdb stacktrace.
>
> #0 Perl_pp_entersub (my_perl=0x6587b0) at
> pp_hot.c:2945
> #1 0x00000000004224f3 in S_call_body
> (my_perl=0x6587b0, myop=0x65a6e0,
> is_eval=1 '\001') at perl.c:2728
> #2 0x00000000004223c4 in Perl_call_sv
> (my_perl=0x6587b0, sv=0x635420, flags=2)
> at perl.c:2607
>
> parts from perl -V
>
> cc='gcc', ccflags ='-D_REENTRANT
> -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
> -fno-strict-aliasing -pipe -I/usr/local/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -I/usr/include/gdbm',
>
> Characteristics of this binary (from libperl):
> Compile-time options: DEBUGGING MULTIPLICITY
> PERL_IMPLICIT_CONTEXT
>
> PERL_MALLOC_WRAP
> THREADS_HAVE_PIDS USE_64_BIT_ALL
>
> USE_64_BIT_INT USE_ITHREADS
> USE_LARGE_FILES
>
> USE_PERLIO USE_REENTRANT_API
>
>
>
>
>
>
