Thu, 26, 2006 at 11:29:36AM -0700, Jerry D. Hedden wrote:
I thought the way to fix this was to move all the static
variables into MY_CXT. However, I couldn't get this to
work. For example, consider putting just the TID counter
into MY_CXT:

typedef struct {
/* Used by Perl interpreter for thread context switching */
ithread *context;

UV tid_counter;
} my_cxt_t;

The problem is as follows. Currently threads.xs, by calling MY_CXT_CLNE,
ensures that the pseudo-static data in

struct { ithread *thread} my_cxt_t

is allocated per interpreter, rather than shared between all threads'
interpreters; while vars like tid_counter need to be shared within each
pool of interpreters.

to put it another way, if a C program embeds two perl interpreters, and
each interpreter runs the following program:

use threads;
thread->new() for 15;

then we should get the following:

BT: called twice;
two pools of interpreters;
within each pool, there is a unique tid_counter, so a total of two
tid_counters
Each pool contains 6 threads, each with an associated interpreter, each of
which has an individual MY_CXT.thread value.

An "easy" fix for this is to add a new per-interpreter var, PL_ithread say,
and use this to point to the ithread structure. Then ditch calling
MY_CXT_CLNE, making the MY_CXT vars per interpreter pool rather than per
interpreter, then shove tid_counter et al. there.

That however has the rather large drawback of tying the threads module
directly to the core.

Fri, 27, 2006 at 01:25:39PM -0700, Jan Dubois wrote:
Well, the MY_CXT macro may not support this directly, but they are
just syntactic sugar around storing values in the PL_modglobal hash
to avoid the hash access if you compile without MULTIPLICITY.

Er, I completely rewrote the MY_CXT* macros a few months ago to make them
a lot more efficient; they no longer use PL_modglobal, and only provide
one struct per source file - due to a static var per file (see START_MY_CXT).

Quoth jdhedden (AT) 1979 (DOT) usna.com:
Jerry writes:
Interesting. I think I know how to fix this, but I have
no idea how to test it. Any suggestions on how to write a
test for this?

Jan Dubois wrote:
You could write an XS module to call perl_alloc(),
perl_construct(), perl_parse(), etc. to create a second
interpreter.

You can control what the 2nd interpreter does by passing
stuff in through the argc,argv options to perl_parse(),
e.g.

"-Mthreads::test -eruntests"

where threads::test is your test module. It exports the
runtests() function that implements your test suite.

I have no idea how to do any of this. Sorry, but it's
beyond my present knowledge. Is there something that does
this sort of thing already that I could use as an example?
would somebody please generate something that I could use
as a starting point?

Perl.pm .

Ben