Note that allocating memory in one (perl) thread and freeing in another is
not natuarlly portable to Win32 perl. In Win32 each thread has its
own malloc pool.

That would be bad, are you sure about this ? This si Win32 limitation or perl threads on Win32 limitation ? I'm currently developing it mainly in unixes, but I hope (tm) to be it portable to windows.


It seems to me that if the "other thread" is (or could be) C++ only,
then the perl scalar that refered to the "message" while it was being
created and filled in or whatever can be free-d at the point that message is handed to the other-thread. At this point ownership of the inner C++ object is handed to the sending thread.
Yes, just does not tell perl that the variable is pointer to object, but bless it into package anyway, right ? And probably make a hash, which will have 'pointers' as key. When the value will be defined, object is 'ours', when it will not be defined, object is in care of other thread.

This sounds to me very promising.

You meen bless integer into the package, and then all functions will convert it back to pointer ? Hmm, never thought about that ... I'm afraid of some automatic conversions or whatever ... but might work.

That is what sv_setref_pv() does ;-)
time to RTFM again :)

Thank you a lot
        Vladimir

Reply via email to