I've posted an update/resolution reg this issue to perl5-porters. FYI

http://markmail.org/message/cjbhybjfikuirvud

--- On Wed, 11/4/09, Sri <w2learn@(protected):

> From: Sri <w2learn@(protected)>
> Subject: Using multiple perl interpreters
> To: modperl@(protected)
> 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
>
>
>
>
>      
>