Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
When you use an external library in Perl, such as e.g. libxml, you have Perl data-structures and libxml data-structures. The Perl data-structures contain pointers to the libxml data-structures.
In comes the starting of an ithread and Perl clones all of the Perl data-structures. But it copies _only_ does things it knows about. And thus leaves the pointers to the libxml data-structures untouched. Now you have 2 Perl data-structures that point to the _same_ libxml data-structures. Voila, instant sharing.
I see. Our library loading code should take care of that. On thread creation we call again the _init code, so that the external lib can prepare itself to be used from multiple threads. But don't ask me about details ;)
But I think we'll never be able to make this work as the user would initially expect. For instance if we have a DBI implementation, and some PMC is holding an external reference to a database cursor for an open transaction, then we can't properly duplicate the necessary state to make the copy of the PMC work correctly (that is, independently). (And I'm not saying just that we can't do it from within parrot, I'm saying the native database libraries can't do this.)
So some objects such as this would always have to end up shared (or else non-functional in the new thread), which is bad for users because they have to be concerned with what objects are backed by native libraries and which ones cannot be made to conform to each of our thread styles.
That seems like a major caveat.
JEff
