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.

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?

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.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other