Vladimir Marek <[EMAIL PROTECTED]> writes: >> Avoiding that is easy - all that a "mortal" SV does is an >> automatic SvREFCNT_dec() on scope exit. So you can de-mortalize >> by SvREFCNT_inc(). >But then the REFCNT counter of the object will not be freed. But yes, >this is still better then not freeing whole object. Thank you for tip. > >> Tk for example is quite like above - when a widget is created >> its object has SvREFCNT_inc'ed higher than you might expect >> and $widget->destroy does corresponding SvREFCNT_dec(s). >> Then perl calls DESTROY which free()s the memory. >Ah, the point is that perl cannot call destructor of the object.
Until allowed to by "something" dropping the REFCNT. > >> But this path risks leaks unless you are very sure that >> destroys get called. >yup > >> Why are you having destroy_object of your own rather than letting >> perl track usage and eventually call DESTROY once? >The object is message which is send over network, which can take quite >lot of time. So another thread handles the sending, and frees the >message when its done. 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. 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. > >>>One solution is to create copy of the object and free that copy, >>>but I would like to do it without copying. >> sv_setref_pv() puts the pointer in the SvIV slot. >> So you can de-associate the SV from the C++ thing by zeroing the SvIV. >> But then destroy_object needs to be prepared to do nothing >> when passed NULL. >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 ;-) > > Thank you > Vladimir Marek
