Stas Bekman <[EMAIL PROTECTED]> writes: > Gisle Aas wrote: > > Stas Bekman <[EMAIL PROTECTED]> writes: > > > >>I've played with it some more. The following program demonstrates some > >>So again perl doesn't provide enough public API to properly juggle > >>perl interpreters. > > I disagree. The API seems fine to me. > > No. > > 1) There is a bug in perl_alloc. As my program (see my previous post > in this thread) demostrates, perl_alloc will not allocate a private > key for a new interpreter (which is proper for perl_clone'd perls, but > broken for a different perl running in the same interpreter. > > 2) PERL_SET_CONTEXT has a problem with using the PL_thr_key key, which > may belong to a totally different interpreter.
The design is that there is only one PL_thr_key shared between all interpreters. This is enough as each thread can only execute in the context of one interpreter at a time. The PL_curintep is only used to as a flag to indicate if the one PL_thr_key has already been allocated or not, as well as remember the "initial parent interpreter under useithreads". As I said in an earlier message, using PL_curintep as a flag makes perl_alloc() slightly thread-un-safe, but if you just make sure to allocate a perl in the parent thread first things should be ok. > And in any case I didn't see perl fixed and it's not quite clear > whether it's going to be fixed at all. That's true. Well, at least ActivePerl is fixed then. :) Regards, Gisle --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
