I'm solving following problem: generally may happen, that somebody has an instance of XML::Sablotron (and of few more packages) allocated in the interperter at the time, the perl is cloned.
Sablotron objects are just wrappers around internal c++ structures, and the only data, they keep, are handles. Some of internal objects are thread safe and may be shared, some must be instantiated per thread.
Any Perl data will be copied for you. Things at the C++ level will have to be taken care of by you. There may be a hook that you can use to do some work whenever a new interpreter is cloned.
I already introduced threadsafe refcounting for all wrapped internals (bot of safe and unsafe) to prevent crashing in destructors (while disposing internal structure from several cloned instances), but currently I do need understand all scenarios, which may happen when handling non-thread safe internals. I need rather to write a documenation, about what the user is allowed, then develop a different model.
In other words: I can keep all object happy when cloned to another threads due the refcounting, but I (user) must grant, that non-threadsafe instances are used across different threads. My original question was aimed right to this point: whether is such a situation even possible. It seems, it is. It it clear? have you got some more comments for me?
There's no chance that the same Perl object will be used in multiple threads, but obviously multiple Perl objects could end up pointing to the same C++ data.
Since cloned Perl interpreters will all point to the same non-perl datastructures, you must make the access to them thread-safe. Since you have already figured out the issue with DESTROY (must have had lots of segfaults before you did ;) you are all set.
I've done something very similar in DBI::Pool prototype, where all access to the shared between threads C struct are mutex locked when accessed.
http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html
Notice that you it should be possible to do the locking from perl (using the threads.pm package, however if you read my bug report it has problems when a thread that didn't load the package tries to access the ithreads env.
http://archive.develooper.com/[EMAIL PROTECTED]/msg00649.html
I'd suggest asking how others are handling making their XS libraries safe across clone calls in a place like comp.lang.perl.misc where more XS wizards tend to hang out. There are some here too though. Anyone have a better answer for Pavel about how to deal with this?
probably you are better off at the [EMAIL PROTECTED] and [EMAIL PROTECTED] lists (however the latter is for ithreads issues).
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
