Hi Przemek,
>>> I also think that it's time to enable by default HB_GC_AUTO. With new
>> +1
>
> I will want to make it optional so users can enable or disable it
> when necessary.
> I can add new _SET_* but like _SET_HBOUTLOG and _SET_HBOUTLOGINFO
> it will be global setting not thread local so I
On Thu, 26 Nov 2009, Szak�ts Viktor wrote:
Hi,
> > I also think that it's time to enable by default HB_GC_AUTO. With new
> +1
I will want to make it optional so users can enable or disable it
when necessary.
I can add new _SET_* but like _SET_HBOUTLOG and _SET_HBOUTLOGINFO
it will be global sett
On Thu, 26 Nov 2009, Tamas TEVESZ wrote:
> > I've just committed it:
> >
> > 2009-11-26 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> a typo seems to have snuck in.
> Index: src/vm/hvm.c
> ===
> --- src/vm/hvm.c
On Thu, 26 Nov 2009, Przemysław Czerpak wrote:
hi,
> I've just committed it:
>
> 2009-11-26 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
a typo seems to have snuck in.
Index: src/vm/hvm.c
===
--- src/vm/hvm.c
> I also think that it's time to enable by default HB_GC_AUTO. With new
+1
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
On Wed, 25 Nov 2009, Przemysław Czerpak wrote:
Hi,
> Yes, but these are very good propositions and quite easy to implement
> so maybe I'll add it soon at least partially.
I've just committed it:
2009-11-26 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbapi.h
On Wed, 25 Nov 2009, Mindaugas Kavaliauskas wrote:
Hi,
[...]
> Since memory can be allocated from any mspace, sometimes it can be
> useful to change hbstack allocator (if two or more threads are using
> the same mspace, but some mspaces are unused - it can happen after
> some thread exits). But t
Hi,
Przemysław Czerpak wrote:
using some logic dependent on GC activation or thread destruction.
See above and do not forget that memory allocated by one thread can
be accessible by other threads so you cannot free mspaces when thread
is destroyed. Anyhow if you want to force freeing unused m
On Tue, 24 Nov 2009, Mindaugas Kavaliauskas wrote:
Hi,
> Thank You for test results. I like the simplicity of DLMT, and I
> think this implementation is better than trying to adapt more
> complex PT*, NED* or other ALLOCs.
They are also using thread local mspaces. The main difference is
caused b
Hi,
Przemysław Czerpak wrote:
As you can see in the last test DLMT has even better scalability what
allows to reduce the speed difference and DLMT was finally a little bit
faster. Anyhow this test uses only 3 threads which very nicely play with
DLMT and I expect that when much bigger number of
On Tue, 24 Nov 2009, Mindaugas Kavaliauskas wrote:
Hi,
> > * harbour/src/vm/fm.c
> >* enabled HB_FM_DLMT_ALLOC by default in MT HVM if HB_FM_DL_ALLOC is
> > also enabled
> BTW, what is HB_FM_DLMT_ALLOC performance in comparison to native
> Linux malloc() (in MT mode of cause)?
It's not
Hi,
* harbour/src/vm/fm.c
* enabled HB_FM_DLMT_ALLOC by default in MT HVM if HB_FM_DL_ALLOC is
also enabled
BTW, what is HB_FM_DLMT_ALLOC performance in comparison to native Linux
malloc() (in MT mode of cause)?
Regards,
Mindaugas
__
Revision: 12970
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12970&view=rev
Author: druzus
Date: 2009-11-22 11:38:17 + (Sun, 22 Nov 2009)
Log Message:
---
2009-11-22 12:38 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
+ harbour/config/linux/
13 matches
Mail list logo
