I believe XS is a weak point in ithreads. ithreads is able to separate data completely at the Perl interpreter level. It is not able to go below this level.

XS code needs to be intimately aware of threading, however it may not need to be explicitly aware.

What I mean by 'intimately aware' is that the designer should review each section of code in the context of an ithread environment to ensure that it will work as expected.

As long as XS code only allocates its own data structures each time it is invoked (no 'static' or global variables), and only changes data passed in using the official Perl API, XS code will function propertly under an ithreads environment.

If the XS code needs to keep static or global data it either needs to ensure that the data is initialized only once and only read later, or it needs to access the data within the context of a lock (mutex, etc.). A third option is that the XS code could use thread-specific data.

First off, thanks for your replies.

As long as XS code only allocates its own data structures each time it is invoked (no 'static' or global variables), and only changes data passed in using the official Perl API, XS code will function propertly under an ithreads environment.

So that means that C static variables are shared, but I can use perl variables in the normal way, right? Are there any specific issues with accessing :shared perl variables from XS?

Joost

-- 
#!/usr/bin/perl -np
BEGIN{@ARGV=$0}s(^([^=].*)|=)()s;
=Just another perl hacker\
[download]

Always follow the API. Specifically this means that you should respect get magic before fetching the value of a variable and set magic after storing a value. get and set magic is used to push shared data back and forth between an interpreter allocated only to hold shared data.