This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Hoarde allocator looks to be the best malloc clone out
there. I need to have a malloc clone anyway, because to do
secure mallocing, I need to be able to get the internal
stats on the malloced block and that's simply not
"standard". Not sure it's standard in Hoarde, but if I
include the code (rather than a dependency) I can fix that.
The main problem I have with Hoarde is that the distributed
source is poorly documented and is a bugbear to compile.
Help with disentanglifying the Hoarde allocator would be
much appreciated!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I must apologise because I used bad wording in my
first message: I used "thread" like it is used in
the mhash man page, that is "hash context structure"
(in nettle speak) or "digest object" (in gcrypt
speak).
Can I suggest not to go too high level with this?
It is a matter of priorities: the second priority
in mhash development should be to add the algorithms
that are in the TODO file.
The first priority, and this was the kernel of my
request, should be to allow a developer to use its
own memory allocator (I have written a Tcl interface
to mhash, that is why I needed it).
At present, I think that a low level interface like
the one of nettle should be made available: allow
the user to allocate the bare context struct where
he wants; if this is accepted, it should be a
priority over new algos because it is a change in
the interface.
Once this is done: everyone is free to study how
to implement secure memory and galaxy allocators.
With bare struct allocation it is straightforward
to write bindings for scripting languages and Lisps,
which, in my opinion, is the number one thing to do
for "mhash marketing".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=572001
How do you think about this?
http://en.wikipedia.org/wiki/Hoard_memory_allocator
Logged In: YES
user_id=1466
In progress.
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
Logged In: YES
user_id=572001
Have you got new considerations about thread-specific
memory allocators?
Logged In: YES
user_id=1466
The Hoarde allocator looks to be the best malloc clone out
there. I need to have a malloc clone anyway, because to do
secure mallocing, I need to be able to get the internal
stats on the malloced block and that's simply not
"standard". Not sure it's standard in Hoarde, but if I
include the code (rather than a dependency) I can fix that.
The main problem I have with Hoarde is that the distributed
source is poorly documented and is a bugbear to compile.
Help with disentanglifying the Hoarde allocator would be
much appreciated!
Logged In: YES
user_id=572001
Would you like to discuss the open issues on a mailing
list?
- http://groups.yahoo.com/group/hoard/
- https://sourceforge.net/mailarchive/forum.php?
forum_id=5134
Logged In: YES
user_id=727156
I must apologise because I used bad wording in my
first message: I used "thread" like it is used in
the mhash man page, that is "hash context structure"
(in nettle speak) or "digest object" (in gcrypt
speak).
Can I suggest not to go too high level with this?
It is a matter of priorities: the second priority
in mhash development should be to add the algorithms
that are in the TODO file.
The first priority, and this was the kernel of my
request, should be to allow a developer to use its
own memory allocator (I have written a Tcl interface
to mhash, that is why I needed it).
At present, I think that a low level interface like
the one of nettle should be made available: allow
the user to allocate the bare context struct where
he wants; if this is accepted, it should be a
priority over new algos because it is a change in
the interface.
Once this is done: everyone is free to study how
to implement secure memory and galaxy allocators.
With bare struct allocation it is straightforward
to write bindings for scripting languages and Lisps,
which, in my opinion, is the number one thing to do
for "mhash marketing".