This is indeed correct:

* You are yourself responsible for not calling into a single interpreter
  from multiple threads at the same time.

* You must make sure that each thread that calls into the Perl interpreter
  calls PERL_SET_CONTEXT() before calling into Perl.

It is also good practice to safe and restore the Perl context.

The Perl context is stored in thread local storage (TLS) and is used by
some Perl APIs that don't explicitly receive the current Perl interpreter
as an argument.  If you don't set this TLS pointer using PERL_SET_CONTEXT
and call one of these Perl APIs (possibly indirectly), then you may
end up crashing.

Cheers,
-Jan

On Thu, 26 Apr 2007, Frank Merrow wrote:
>  I'm not sure if this applies to your situation or not.
> 
>  In my case, I have a large multi-threaded application.
> 
>  While I have not found any "documentation" on the subject, by
>  testing I found that calls to the Perl DLL do not multi-thread well.
>  In fact, even if you use a semaphore to make sure only one thread
>  enters the DLL at a time it still doesn't work . . . or at least
>  didn't work for me.
> 
>  To finally get things to work, I created a special "Perl Thread"
>  which blocks on a semaphore and has a mailbox for the perl code I
>  want to run.
> 
>  Once I made sure that the Perl DLL was called only by its own
>  dedicated thread . . . it all straightened up and started working.
> 
>  Frank
> 
>  At 06:36 AM 4/26/2007, Caminati Carlo wrote:
>  > Hello
>  >
>  > I have a really strange problem with perlembed
>  >
>  > the following fragment of C uses a persistent interpreter and lives
>  > in a DLL
>  >
>  > the function TrapFwPFisToBeSent is called by a main program a lot of
>  > times. I have the following cases:
>  >
>  > - in a test environment (same DLL called my a small main) -> all OK
>  >
>  > - in production environment (same DLL called within a large
>  >   framework including SNMP libraries, HP OpenView libraries and so
>  >   on) -> in a lot of cases the first newSVpvn raises an exception
>  >   caught by the caller of this function. In some cases the calls are
>  >   ok and I get the result of the Perl routine. I'm not able to
>  >   extract a rule to understand why it fails on some cases and not in
>  >   some others. I also took a look to the disassembly of perl58.dll
>  >   but I'm only able to see that it crashesc (Access violation,
>  >   typical of accessing to protected memory).
>  >
>  > - the problem is present also if the subroutine 'isToBeSent' is an
>  >   empty container like following:
>  >
>  >                                 sub isToBeSent { my ($node,$text) =
>  >                                 @_; my $send = 1; return $send; }
>  >
>  >    this confirms to me that the problem is in 'newSVpvn' (I tried
>  >    also newSVpv with the same result).
>  >
>  >
>  > any ideas ?
>  >
>  > TIA
>  >
>  > Carlo
>  >
>  > ------------------------------------------------------------------------


_______________________________________________
Perl-Win32-Porters mailing list
Perl-Win32-Porters@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs