Re: [fpc-devel] missed ddk window hints
On Thu, 7 Aug 2008, Paul Ishenin wrote: > Hello, FPC developers' list > > Please apply this patch and merge into fixes if possible. Patched and merged. It's not in 2.2.2, though. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] missed ddk window hints
Michael Van Canneyt wrote: On Thu, 7 Aug 2008, Paul Ishenin wrote: Hello, FPC developers' list Please apply this patch and merge into fixes if possible. Patched and merged. It's not in 2.2.2, though. Thanks. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
Am Mittwoch, 6. August 2008 21:37 schrieb Sergei Gorelkin: > Mattias Gaertner wrote: > > On Wed, 6 Aug 2008 19:41:27 +0100 > > > > "Inoussa OUEDRAOGO" <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> TAVLTree in avl_tree.pp is not thread safe due to the node > >> allocation and de-allocation done through the global > >> declared "NodeMemManager" variable. TAVLTreeNodeMemManager > >> implementation is cleary not thread safe, which btw IMHO > >> is a good thing ( for performance reason). > >> > >> Proposition : > >> > >> (a) TAVLTree should allow, at construct time, to > >> specify a Node memory manager which will be kept and used. > >> If not specified the global one will be used. > >> > >> (b) "NodeMemManager" should be declared as "ThreadVar". > >> > >> This changes does not break the API while making the > >> implementation thread safe. > >> > >> By the way note that the XML DOM's implementation > >> ( TDOMNode_WithChildren ) uses TAVLTree, so every code that uses > >> the fcl-xml package mainly the DOM unit, is not thread safe. If > >> this proposition is accepted it will be nice to have it introduced > >> in the soon to be release fpc 2.2.2, in the case that is still > >> possible, mainly for server programming. > >> > >> Attached is a patch that demonstrate the above proposition. > > > > Providing a local node mem manager does not repair xml dom. > > > > Maybe move NodeMemManager to the interface, so that a user can > > replace it with a threadsafe one? > > Since this topic is touched, I would like to vote for removing > avl_tree dependency from the DOM altogether. The reason is that the > avl tree of child nodes is useless for any real-world XML data > because it does not handle duplicate names. The tree is useful only > for the one particular case of XML configs where each node name is > unique. OTOH, it causes considerable performance penalties (each > insert results in two searches, first one for checking the existence, > second one for insert itself; each search is a number of calls to > Node.GetNodeName, which, in case of Windows, is a Widestring copy, > etc.) > Therefore I'd suggest to remove the avltree from DOM. This would be great to have in 2.2.2. > In order to > keep configs at the reasonable speed, it is possible to implement > indexing within TXMLConfig class itself, preferably hashmap-based. This would be a performance tweak which (from my POV) does not need to be in 2.2.2, although it would be nice. > Alternatively, it is possible to use Registry-like access > (OpenKey/CloseKey methods) that I had already implemented in newer > xmlconf.pp unit. The advantage is that the searches are done starting > from the 'opened key', not from the root, so linear search isn't too > slow. If I understand correctly, this would change the usage of xmlconfig which would require changes to any existing code using it? If so, it's probably not an option for 2.2.2, maybe even not for 2.2.4 .. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
Zitat von Burkhard Carstens <[EMAIL PROTECTED]>: > Am Mittwoch, 6. August 2008 21:37 schrieb Sergei Gorelkin: > > Since this topic is touched, I would like to vote for removing > > avl_tree dependency from the DOM altogether. The reason is that the > > avl tree of child nodes is useless for any real-world XML data > > because it does not handle duplicate names. The tree is useful only > > for the one particular case of XML configs where each node name is > > unique. OTOH, it causes considerable performance penalties (each > > insert results in two searches, first one for checking the existence, > > second one for insert itself; each search is a number of calls to > > Node.GetNodeName, which, in case of Windows, is a Widestring copy, > > etc.) The widestrings version is slow under linux too. Last time I tested (a few months ago) it was about 2 to 10 times slower than the ansistring version. Mainly because of the parser. > > Therefore I'd suggest to remove the avltree from DOM. > > This would be great to have in 2.2.2. > > > In order to > > keep configs at the reasonable speed, it is possible to implement > > indexing within TXMLConfig class itself, preferably hashmap-based. > > This would be a performance tweak which (from my POV) does not need to > be in 2.2.2, although it would be nice. The performance penalty without the trees can be quite big for things like txmlconfig. For example for lazarus project files it can be a hundred times slower without the trees. Note: lazarus itself uses its own ansistring version of xml parser, so this not a direct problem for lazarus. > > Alternatively, it is possible to use Registry-like access > > (OpenKey/CloseKey methods) that I had already implemented in newer > > xmlconf.pp unit. The advantage is that the searches are done starting > > from the 'opened key', not from the root, so linear search isn't too > > slow. > > If I understand correctly, this would change the usage of xmlconfig > which would require changes to any existing code using it? If so, it's > probably not an option for 2.2.2, maybe even not for 2.2.4 .. I second that. The main advantage of TXMLConfig is it's easy usage. I guess you can gain some speed by implementing some kind of caching for paths. Maybe I will do that for the lazarus ansistring version. But IMO this is too risky for fpc 2.2.2 which is released soon. About avl tree: For thread safety I guess the best thing is to not use the node mem manager. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
Am Mittwoch, 6. August 2008 20:41 schrieb Inoussa OUEDRAOGO: > Hi, > > TAVLTree in avl_tree.pp is not thread safe due to the node > allocation and de-allocation done through the global > declared "NodeMemManager" variable. TAVLTreeNodeMemManager > implementation is cleary not thread safe, which btw IMHO > is a good thing ( for performance reason). > > Proposition : > > (a) TAVLTree should allow, at construct time, to > specify a Node memory manager which will be kept and used. > If not specified the global one will be used. > > (b) "NodeMemManager" should be declared as "ThreadVar". > > This changes does not break the API while making the > implementation thread safe. > > By the way note that the XML DOM's implementation ( > TDOMNode_WithChildren ) uses TAVLTree, so every code that uses the > fcl-xml package mainly the DOM unit, is not thread safe. If this > proposition is accepted it will be nice to have it introduced in the > soon to be release fpc 2.2.2, in the case that is still possible, > mainly for server programming. > > Attached is a patch that demonstrate the above proposition. What about this: * let TAVLTree access the node manager using a local reference (TAVLTree.FNodeMemManager) * in TAVLTree.create: if IsMultiThread then FNodeMemManager:=TAVLTreeNodeMemManager.create else FNodeMemManager:=NodeMemManager; * in TAVLTree.destroy: if IsMultiThread then FNodeMemManager.free; This way, nothing would change for single threaded apps but it would be fully threadsafe for multithreaded (AFAIKS). This is probably not a perfect solution, but the least intrusive one .. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
> Am Mittwoch, 6. August 2008 20:41 schrieb Inoussa OUEDRAOGO: > What about this: > * let TAVLTree access the node manager using a local reference > (TAVLTree.FNodeMemManager) > * in TAVLTree.create: > if IsMultiThread then > FNodeMemManager:=TAVLTreeNodeMemManager.create > else > FNodeMemManager:=NodeMemManager; > * in TAVLTree.destroy: > if IsMultiThread then > FNodeMemManager.free; > > This way, nothing would change for single threaded apps but it would be > fully threadsafe for multithreaded (AFAIKS). This is probably not a > perfect solution, but the least intrusive one .. I would add nodemgr as parameter to create, but with a default value of nil. If not NIL then just grab the default nodemanager. That way, people with multithreading concerns can override, and it is perfectly backwards compatible. There is no good system to do this kind of stuff automatic: - I might have threads but only read a xml config in the mainthread, no need for locks - I might have a dozen xml readers somewhere, and they all get an own pool of nodes, inflating memory. _IF_ it is multithread. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bug in GetAppConfigDir(True) on unix systems!
Hi, Calling GetAppConfigDir(True) returns the wrong results... In my application I expected /etc// but instead it returned /etc/ Note the missing directory separator! ---[ rtl/unix/sysutils.pp ]--- Function GetAppConfigDir(Global : Boolean) : String; begin If Global then Result:=SysConfigDir else Result:=XdgConfigHome; if VendorName<>'' then Result:=IncludeTrailingPathDelimiter(Result+VendorName); //<=== No dir separator??? Result:=IncludeTrailingPathDelimiter(Result+ApplicationName); //<=== No dir separator??? end; SysConfigDir is set to '/etc' for unix systems. No trailing directory separator. Above I indicated two places where the directory separator must be added. I'm using FPC 2.2.3 r11214. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
Am Donnerstag, 7. August 2008 11:15 schrieb Burkhard Carstens: [...] > > What about this: > * let TAVLTree access the node manager using a local reference > (TAVLTree.FNodeMemManager) > * in TAVLTree.create: > if IsMultiThread then > FNodeMemManager:=TAVLTreeNodeMemManager.create > else > FNodeMemManager:=NodeMemManager; > * in TAVLTree.destroy: > if IsMultiThread then > FNodeMemManager.free; > > This way, nothing would change for single threaded apps but it would > be fully threadsafe for multithreaded (AFAIKS). This is probably not > a perfect solution, but the least intrusive one .. This would have been too easy :-) IsMultiThread is false until the first thread is started, so we can't use that. However, we could use a global var in avl_tree interface like "var ThreadSafeAVLTree : boolean = false;" instead. This way, we don't have it threadsafe automatically, but if needed, the developer can set this to true before instantiating the first AVLTree. This is still more than we have now without breaking anything existing .. A big "Note: if you want to use it in multithreaded app, please set ThreadSafeAVLTree:=true; before creating the first instance" in the docs of AVLTree and XML would be helpfull of course. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
Am Donnerstag, 7. August 2008 11:28 schrieb Marco van de Voort: > > Am Mittwoch, 6. August 2008 20:41 schrieb Inoussa OUEDRAOGO: > > What about this: > > * let TAVLTree access the node manager using a local reference > > (TAVLTree.FNodeMemManager) > > * in TAVLTree.create: > > if IsMultiThread then > > FNodeMemManager:=TAVLTreeNodeMemManager.create > > else > > FNodeMemManager:=NodeMemManager; > > * in TAVLTree.destroy: > > if IsMultiThread then > > FNodeMemManager.free; > > > > This way, nothing would change for single threaded apps but it > > would be fully threadsafe for multithreaded (AFAIKS). This is > > probably not a perfect solution, but the least intrusive one .. > > I would add nodemgr as parameter to create, but with a default value > of nil. If not NIL then just grab the default nodemanager. You mean "if nodemgr = nil" then grab the global one ? This wouldn't help much for the xml stuff or other things using avltree internally (if there are any), unless you introduce this additional parameter there, too. > That way, people with multithreading concerns can override, and it is > perfectly backwards compatible. > > There is no good system to do this kind of stuff automatic: > - I might have threads but >only read a xml config in the mainthread, no need for locks > - I might have a dozen xml readers somewhere, and they all get an own > pool of nodes, inflating memory. _IF_ it is multithread. That's true, but considering the fact that it's not threadsafe at all now .. even worse: consider a multithreaded app, that uses an avltree in one thread and a xmldocument in another thread ... this would give hard to find strange errors and the user (developer) doesn't even see a relation between avltree and xml, unless he digs into xml sources .. However, see my other reply to my own post: using "IsMultiThread" won't work anyway so I already refrained from auomatic handling. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
> Am Donnerstag, 7. August 2008 11:28 schrieb Marco van de Voort: > > > > I would add nodemgr as parameter to create, but with a default value > > of nil. If not NIL then just grab the default nodemanager. > > You mean "if nodemgr = nil" then grab the global one ? > This wouldn't help much for the xml stuff or other things using avltree > internally (if there are any), unless you introduce this additional > parameter there, too. Correct. But better do it correct directly. The kind of workarounds described here are fine for a single app, but not something you put in libs. > > That way, people with multithreading concerns can override, and it is > > perfectly backwards compatible. > > > > There is no good system to do this kind of stuff automatic: > > - I might have threads but > >only read a xml config in the mainthread, no need for locks > > - I might have a dozen xml readers somewhere, and they all get an own > > pool of nodes, inflating memory. _IF_ it is multithread. > > That's true, but considering the fact that it's not threadsafe at all > now .. even worse: consider a multithreaded app, that uses an avltree > in one thread and a xmldocument in another thread ... this would give > hard to find strange errors and the user (developer) doesn't even see a > relation between avltree and xml, unless he digs into xml sources .. If you are so worried about that, give the XML units an own avl node mgr, that they always pass. But IMHO doing it right is important now. Btw, this is also one of the reasons why I never do significant work in a constructor. This way, you always have to expand parameters in the constructor, facing incompabilities and inheritance problems. If the constructor doesn't do stuff like loading the file, you can simply use a setter. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Bug in GetAppConfigDir(True) on unix systems!
GetAppConfigFile() has the same issue. On Thu, Aug 7, 2008 at 11:30 AM, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > Hi, > > Calling GetAppConfigDir(True) returns the wrong results... > > In my application I expected > > /etc// > > but instead it returned > > /etc/ > > > Note the missing directory separator! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Bug in GetAppConfigDir(True) on unix systems!
This is fixed in fpc-trunk a few weeks ago. I'll morge it to fixes. Joost Op donderdag 07-08-2008 om 12:01 uur [tijdzone +0200], schreef Graeme Geldenhuys: > GetAppConfigFile() has the same issue. > > > > On Thu, Aug 7, 2008 at 11:30 AM, Graeme Geldenhuys > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Calling GetAppConfigDir(True) returns the wrong results... > > > > In my application I expected > > > > /etc// > > > > but instead it returned > > > > /etc/ > > > > > > Note the missing directory separator! > > > > Regards, > - Graeme - > > > ___ > fpGUI - a cross-platform Free Pascal GUI toolkit > http://opensoft.homeip.net/fpgui/ > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
Second proposition :
Another proposition is to introduce a base avl class say TBaseAVLTree
that defines two abstract virtual methods "NewNode()" and "FreeNode()"
and then define :
- TAVLTree : that _do not_ use a node mem manager, then thread safe.
- TAVLManagedTree that uses a node mem manager provided in the constructor.
The developer using this one is _aware_ of the thread safety issue and can
then provide a thread safe node mem manager for an instance exposed
to more than one thread while using the default not thread safe node
mem manager for a thread local instance.
For the record, even if each thread has a non-thread-safe node mem manager
the issue remains : ThreadA create a avl and populate it. ThreadB
delete some nodes of that avl. The deleted nodes have been created
using ThreadA's node mem manager while collected by ThreadB's node mem manager.
ThreadA and ThreadB could be using different node mem manager implementations.
TBaseAVLTree = class
...
protected
function NewNode() : TAVLTreeNode;virtual;abstract;
procedure FreeNode(ANode : TAVLTree);virtual;abstract;
...
end;
TAVLTree = class(TBaseAVLTree)
protected
function NewNode() : TAVLTreeNode;override;
{ implemented as
begin
Result:=TAVLTreeNode.Create();
end;}
procedure FreeNode(ANode : TAVLTree);override;
{ implemented as
begin
if ( ANode <> nil ) then
ANode.Free();
end;}
end;
TAVLManagedTree = class(TBaseAVLTree)
private
FNodeMemManager : TAVLTreeNodeMemManager;
protected
// these implementations use FNodeMemManager
function NewNode() : TAVLTreeNode;override;
procedure FreeNode(ANode : TAVLTree);override;
public
constructor Create(OnCompareMethod: TListSortCompare;
ANodeMemManager : TAVLTreeNodeMemManager);
end;
--
Inoussa O.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
Mattias Gärtner wrote:
Zitat von Burkhard Carstens <[EMAIL PROTECTED]>:
Am Mittwoch, 6. August 2008 21:37 schrieb Sergei Gorelkin:
Since this topic is touched, I would like to vote for removing
avl_tree dependency from the DOM altogether. The reason is that the
avl tree of child nodes is useless for any real-world XML data
because it does not handle duplicate names. The tree is useful only
for the one particular case of XML configs where each node name is
unique. OTOH, it causes considerable performance penalties (each
insert results in two searches, first one for checking the existence,
second one for insert itself; each search is a number of calls to
Node.GetNodeName, which, in case of Windows, is a Widestring copy,
etc.)
The widestrings version is slow under linux too. Last time I tested (a few
months ago) it was about 2 to 10 times slower than the ansistring version.
Mainly because of the parser.
This will change soon. I've almost completed the improved parser which
is very competitive with ansistring one (about 3 times faster than
current implementation, twice faster than MSXML parser).
Therefore I'd suggest to remove the avltree from DOM.
This would be great to have in 2.2.2.
In order to
keep configs at the reasonable speed, it is possible to implement
indexing within TXMLConfig class itself, preferably hashmap-based.
This would be a performance tweak which (from my POV) does not need to
be in 2.2.2, although it would be nice.
The performance penalty without the trees can be quite big for things like
txmlconfig. For example for lazarus project files it can be a hundred times
slower without the trees.
Note: lazarus itself uses its own ansistring version of xml parser, so this not
a direct problem for lazarus.
Alternatively, it is possible to use Registry-like access
(OpenKey/CloseKey methods) that I had already implemented in newer
xmlconf.pp unit. The advantage is that the searches are done starting
from the 'opened key', not from the root, so linear search isn't too
slow.
If I understand correctly, this would change the usage of xmlconfig
which would require changes to any existing code using it? If so, it's
probably not an option for 2.2.2, maybe even not for 2.2.4 ..
I second that. The main advantage of TXMLConfig is it's easy usage.
I guess you can gain some speed by implementing some kind of caching for paths.
Maybe I will do that for the lazarus ansistring version. But IMO this is too
risky for fpc 2.2.2 which is released soon.
xmlconf is source-level compatible with xmlcfg, you can replace it in
uses clause and the code should remain working (although slower). Later
on, you can start replacing things like
s1 := cfg.readstring('foo/bar/value1');
s2 := cfg.readstring('foo/bar/value2');
with
cfg.OpenKey('foo/bar');
s1 := cfg.readstring('value1');
s2 := cfg.readstring('value2');
cfg.CloseKey;
In this simplest example, the code becomes more complicated. However,
most real projects compose the paths from parts, and they no longer need
to do that.
The above also means that the key caching implemented in xmlconf may be
back-ported to xmlcfg without breaking the existing user code.
Sergei
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Bug in GetAppConfigDir(True) on unix systems!
On 8/7/08, Joost van der Sluis <[EMAIL PROTECTED]> wrote: > This is fixed in fpc-trunk a few weeks ago. I'll morge it to fixes. Umm, I knew I had to fix the tiOPF unit tests ages ago, that way I would have detected the bug much earlier. :) I'll get another update of Fixes branch, thanks Joost! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
Inoussa OUEDRAOGO wrote: - TAVLManagedTree that uses a node mem manager provided in the constructor. The developer using this one is _aware_ of the thread safety issue and can then provide a thread safe node mem manager for an instance exposed What is exactly the add-on value for the node mem manager? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
2008/8/7 Micha Nelissen <[EMAIL PROTECTED]>: > Inoussa OUEDRAOGO wrote: >> >> - TAVLManagedTree that uses a node mem manager provided in the >> constructor. >> The developer using this one is _aware_ of the thread safety issue and >> can >> then provide a thread safe node mem manager for an instance exposed > > What is exactly the add-on value for the node mem manager? I guess performance, as it is a pooled factory. I have not test it myself though. -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
On Thu, 07 Aug 2008 18:04:32 +0200 Micha Nelissen <[EMAIL PROTECTED]> wrote: > Inoussa OUEDRAOGO wrote: > > - TAVLManagedTree that uses a node mem manager provided in the > > constructor. The developer using this one is _aware_ of the thread > > safety issue and can then provide a thread safe node mem manager > > for an instance exposed > > What is exactly the add-on value for the node mem manager? Only speed. So it is only needed for such things like the codetools which can create a million nodes. For xml is it probably not that important. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
> Inoussa OUEDRAOGO wrote: > > - TAVLManagedTree that uses a node mem manager provided in the constructor. > >The developer using this one is _aware_ of the thread safety issue and > > can > >then provide a thread safe node mem manager for an instance exposed > > What is exactly the add-on value for the node mem manager? I can only think of heap fragmentation and reduction of creation overhead. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
Marco van de Voort wrote: Inoussa OUEDRAOGO wrote: - TAVLManagedTree that uses a node mem manager provided in the constructor. The developer using this one is _aware_ of the thread safety issue and can then provide a thread safe node mem manager for an instance exposed What is exactly the add-on value for the node mem manager? I can only think of heap fragmentation and reduction of creation overhead. Yes, but fpc's memory manager also already does this (at least if the allocation size is less than 512 bytes or so). Before very complex multithreaded implementations are thought up and implemented, it would be wise to see if there really is a significant enough performance boost with the node manager. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
