On Fri, 15 Feb 2008, Marek Paliwoda wrote:
> >Marek you said that you are using mark/sweep functions extensively.
> >Is it only for marking external HB_ITEMs or for sth else.
> You probably misunderstood me, or I was not clear enouch responding
> to Mindaugas. In a post to Mindaugas I was refering
Marek Paliwoda wrote :
I was not reffering to using hb_gc(Un)RegisterSweep(), especially
to protect pure GC blocks, because unlike you, I cannot imagine
any funcionality where such a feature could be utilized, as oposed
to returning such a block to PRG level and to store it there. I'd
greatly ap
Hi Przemek,
I do not want to remove it yet because I can imagine some interesting
functionality for it without touching HB_ITEM internals though it will
be necessary to add one additional function for it: hb_gcMark( pGCBlock ).
And this is the reason why I asked about it. Does anyone created som
On Tue, 12 Feb 2008, Ryszard Glab wrote:
> OK, I can agree on such restictions however we will have to
> document
> that the pointer allocated with hb_gcAlloc() have to be attached
> using
> hb_gcAttach() function to some item - the item have to be allocated
> using hb_itemNew().
> Or alter
> I have an idea - temporarily add a call to function
> void hb_gcGripTest( PHB_ITEM pItem )
> from for example hb_itemClear() and hb_itemCopy().
Sorry, not so good idea...
Best regards,
Mindaugas
___
Harbour mailing list
Harbour@harbour-project.org
h
Przemyslaw Czerpak wrote:
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
Marek Paliwoda wrote:
Yes, I think it's a good idea. We do not have many problem with GC in
3rd party software, because nobody are using collectible pointers yet,
Do you mean 3rd party software available publicly, or 3rd party software
used privately ? In the latter case it's not true, because
Mindaugas,
Yes, I think it's a good idea. We do not have many problem with GC in
3rd party software, because nobody are using collectible pointers yet,
Do you mean 3rd party software available publicly, or 3rd party software
used privately ? In the latter case it's not true, because I have be
Hi,
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).
I was thinking about it, but I didn't know that GC pointers can be
locked
On 12 Feb 2008 at 3:12, Przemyslaw Czerpak wrote:
> I want to reduce API functions which may cause internal errors
> in different places when are used in wrong way. And hb_gcLock()/
> hb_gcUnlock() are potentially such functions. Now I do not see any
> code which may need it as long as it does not
On Tue, 12 Feb 2008, Ryszard Głąb wrote:
> 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 r
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.
>
>
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 s
Hi,
thanks for replay.
I expect pointer not to be collected, because it "lives" in variable h.
What's wrong with my code?
The reference counter.
...
If you need the exact technical
answer what was wrong in your code then this is hacked version
of your code to work properly. Please never tr
On 2008.02.02., at 15:03, Marek Paliwoda wrote:
Marek Paliwoda pisze:
because I am an author of an original idea, and
In fact, the original author of this idea was *Ryszard*
(sorry Ryszard, I forgot this), but he only used it internally,
inside GC. What I did was exposing this idea to public
On 2008.02.02., at 14:01, Marek Paliwoda wrote:
Hi Viktor,
Similarly to hb_parptr() it stores pointer,
No, it retrieves pointer, not stores it.
> but unlike hb_parptr() you can attach a callback function
No, you do not attach a callback function in hb_parptrGC.
Attachement is done inside
Marek Paliwoda pisze:
because I am an author of an original idea, and
In fact, the original author of this idea was *Ryszard*
(sorry Ryszard, I forgot this), but he only used it internally,
inside GC. What I did was exposing this idea to public, by
introducing "finalizers" for HB_IT_POINTER als
Hi Viktor,
Similarly to hb_parptr() it stores pointer,
No, it retrieves pointer, not stores it.
> but unlike hb_parptr() you can attach a callback function
No, you do not attach a callback function in hb_parptrGC.
Attachement is done inside hb_gcAlloc(). See the sources.
to the variable, w
On Sat, 02 Feb 2008, Mindaugas Kavaliauskas wrote:
> Hi,
> I expect pointer not to be collected, because it "lives" in variable h.
> What's wrong with my code?
The reference counter. Multiple putting the same pointer in
GC pointer item is not safe. If you think that it should be
safe then I can a
Przemyslaw Czerpak pisze:
On Sat, 02 Feb 2008, Marek Paliwoda wrote:
Hi All,
void* ptr = hb_parptrGC( hb_fctx_destructor, 1 );
Could someone explain me what is the purpose of hb_parptrGC() ?
It's used for verification if given parameter holds pointer item
with pointer which points to str
Hi Marek,
Similarly to hb_parptr() it stores pointer, but
unlike hb_parptr() you can attach a callback function
to the variable, which will get control when the
Harbour level variable will be released, and last
but not least the memory associated with the pointer
(allocated using hb_gcAlloc()) wi
On Sat, 02 Feb 2008, Marek Paliwoda wrote:
> Hi All,
> > void* ptr = hb_parptrGC( hb_fctx_destructor, 1 );
> Could someone explain me what is the purpose of hb_parptrGC() ?
It's used for verification if given parameter holds pointer item
with pointer which points to structure allocated by
hb_gc
Szakáts Viktor escribió:
[ yes Javier, but also notice that indenting is just two
chars deep, not to mention the usage of 'begindump'.. :-P ]
I take note :'(
I think the problem is that you're reassigning
'h' after debug( "1" ), which makes it lose it's
value, thus initiating the destructor,
Hi All,
void* ptr = hb_parptrGC( hb_fctx_destructor, 1 );
Could someone explain me what is the purpose of hb_parptrGC() ?
--
Marek
--
Zmus swojego faceta, zeby to przeczytal
Kliknij >>> http://link.interia.pl/f1ceb
__
Hi Mindaugas,
On 2008.02.02., at 4:18, Javier wrote:
Mindaugas Kavaliauskas escribió:
What's wrong with my code?
h ... YA TA! "hb_fctx_destructor" is forbidden by the boss. You
should rename it with "My_destructor". :)
[ yes Javier, but also notice that indenting is just two
chars de
Mindaugas Kavaliauskas wrote:
>
> Hi,
>
>
> I expect pointer not to be collected, because it "lives" in variable h.
> What's wrong with my code?
>
>
> Best regards,
> Mindaugas
>
>
> PROC main()
> LOCAL h
>h := myfunc( h )
>debug( "1" )
>h := myfunc( h )
>debug( "2" )
>
Mindaugas Kavaliauskas escribió:
What's wrong with my code?
h ... YA TA! "hb_fctx_destructor" is forbidden by the boss. You
should rename it with "My_destructor". :)
Sorry it is sophisticated of course, please, could you explain it more.
What is you output?
Best regards
Xavi
___
Hi,
I expect pointer not to be collected, because it "lives" in variable h.
What's wrong with my code?
Best regards,
Mindaugas
PROC main()
LOCAL h
h := myfunc( h )
debug( "1" )
h := myfunc( h )
debug( "2" )
h := myfunc( h )
debug( "3" )
RETURN
#pragma begindump
#include "hbapi
28 matches
Mail list logo
