Ugh.

Spent the better part of the day analyzing the code to mod_perl (the only thing other than Perl itself I could think of that embeds the Perl interpreter). Trying to get a handle on the most reliable way to use all the macros for calling eval_pv, eval_sv, call_pv, etc. (ENTER, LEAVE, PUTBACK, FREETMPS, PUSHMARK, SAVETMPS). What happens when you make multiple calls? When are the contexts cleaned up? The fun that is perlapi, perlcall, perlxs, perlxstut, perlthrtut, perlguts.

Then I discovered this wonderful little gem:

  EmbeddedPerl *ep3 = new EmbeddedPerl();  
  EmbeddedPerl *ep2 = new EmbeddedPerl(); 
  delete ep3;
  delete ep2;

crashes my test rig. It turns up there is some bug in my code where if you have multiple interpreters defined at the same time in the same thread the perl_destroy() code doesn't do deallocation properly of the stack on the second instance (at least on Win32, that is).

Shit. Looks like the one XS module I have in the entire stack is not threadsafe. But this isn't even a thread-safeness issue since both interpreters are on the same thread. It's really multiplicity.

I'm going home now. I really need someone to help me write a series of test cases for my Embedded Perl. Marty, where the hell are you?

P.S. Xerces leaks about six kilobytes per instance of the interpreter. Need to look at whether their SWIG bindings expect some explicit deallocation routine to be called in an END block or something.