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.