Pavel Hlavnicka wrote:
Thanks again,
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. 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?
Thank you very very much
Pavel
