Przemyslaw Czerpak <[EMAIL PROTECTED]> napisał(a): > I think that it will greatly reduce possible mistakes and also your > first example will work as you wanted. hb_gcLock()/hb_gcUnlock() are > a little bit too low level for me if possible then they should be > eliminated from 3-rd party API. > > Opinions? Ryszard you are original author of hb_gc*() functions. > What do you think about it.
OK, hb_gcAlloc() can automatically lock the pointer however we still have to have hb_gcUnlock() function to unlock it distinctly after the assignment to the item stored inside the iternal VM storages (local stack, statics, etc). If the item will remain locked then it will be never released by the GC. Poiters cannot be indirectly unlocked during hb_itemPutPtrGC because using the following code: HB_ITEM item; item.type = HB_IT_NIL; hb_itemPutPtrGC( &item, hb_gcAlloc( size, someFunc ) ); will end with an item storing an unlocked pointer that will be released prematurely by the GC. In summary, current code is safe if there is no call to hb_gcCollect() in initialization code (in other words: between hb_gcAlloc() and the assignment to an item known to the GC). If you plan to run the GC in separate thread then for sure hb_gcAlloc() should return locked pointer however the pointer will have to be unlocked distinctly by the call to hb_gcUnlock() after the asignment. I don't understand what you mean writing 'automatic GC call' then it is possible that we are talking aout different things but currently I will leave gcLock/gcUnlock as they are. > BTW I would like to also ask about real usage of marksweep function. > I know what it does but is it still necessary for 3-rd party code > with current GC? Can someone who uses it say what is its exact job > in his code? I have added this functionality to use it in future sql rdd. I am still at design phase but I plan to use a linked list of rows (or pages) returned by the sql client. Every row will store the HB_ITEM structure. I don't want to use array because of reallocation problems. This linked list will be stored probably in workarea structure. Thus I need some method to prevent deallocation of values stored in this internal workarea space. Regards, Ryszard _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
