On Sat, 02 Feb 2008, Mindaugas Kavaliauskas wrote:
> >Multiple putting the same pointer in
> >GC pointer item is not safe. If you think that it should be
> >safe then I can add such functionality but in such case IMHO
> >I should also update hb_itemPutCPtr() to be safe for multiple
> >putting the same string pointer.
> Perhaps it's a big change, and it seems we manage OK with string
> pointers (well, in most times...). So, we just need to get used to
> pointers also.
No. In fact it's minor modification. It will be enough to initialize
referece counter with 0 and add hb_xRefInc() in hb_itemPut*() functions.
But this modifications should be bound with yet another one (see below).
> >But you can also change your code:
> >...
> > HB_FUNC( MYFUNC )
> > {
> > PHB_ITEM pItem = NULL;
> > void* ptr = hb_parptrGC( hb_fctx_destructor, 1 );
> > if( ! ptr )
> > {
> > ptr = hb_gcAlloc( 4, hb_fctx_destructor );
> > pItem = hb_itemPutPtrGC( NULL, ptr );
> > /* now ptr is safe and you do not have to worry that
> > * it can be removed by some code inside <other code>
> > * which may activate GC
> > */
> > }
> > /* <other code> */
> > if( pItem )
> > hb_itemReturnRelease( pItem );
> > else
> > hb_itemReturn( hb_param( 1, HB_IT_ANY ) );
> > }
> This code is OK for me, thanks. I'm also surprised, that You've answer
> one more question, I haven't asked for!!! The question was: after
> hb_gcAlloc() no item is pointing to pointer, could it be freed by GC?
And hb_gcAlloc() is sth what should be modified yet. This function
returns pointer which is not locked (hb_gcLock()/hb_gcUnlock()) and
can be freed by GC if we do not lock it or attach to GC known item.
When we add automatic GC call then it may be a problem for some 3-rd
party code. If you look at core code then you will find that I
intentionally changed the order of allocating data for arrays, hashes,
codeblocks and some collectible pointer items to eliminate potentially
danger situations. I know how it should be done and it was easy for me.
But it may be serious problem for 3-rd party code developers who do
not know details of our HVM and GC and when/where it can be automatically
activated in the future. Now if they want to be sure that nothing wrong
will happen in <initialization code> they should make sth like:
ptr = hb_gcLock( hb_gcAlloc( ptr ) );
<initialization code>
hb_itemPutPtrGC( ptr, destructorFunc );
hb_gcUnock( ptr );
IMHO hb_gcLock() should return LOCKED pointer and hb_itemPutPtrGC() should
unlock it automatically and increase reference counter (modification above).
In such case the same code will look like:
ptr = hb_gcAlloc( ptr );
<initialization code>
hb_itemPutPtrGC( ptr, destructorFunc );
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.
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?
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
