I also noticed that the draft implementation is not complete, hence my
comment on future enhancements. I definately think your idea to unify
dynamic memory allocation/dellocation is great, which is why I threw
myself over the source to try to make the draft a little easier to make
changes to that will apply for all emem_chunk_t types at once.
When it comes to the api I guess they are reasonable (without having
verified against every other usage of g_malloc).
Perhaps the emem_packet_alloc and emem_capture_alloc functions should
return a void* rather than a char* to be consistent with the return value
of g_malloc?
/ Peter
ronnie sahlberg said:
> 1 and 2 are good points.
>
> the current implementation will not work anyway since it never reuses
> more than the very first memchunk alloced after they have been
> released anyway.
> it needs a free/used list of such emem chunks from a top node.
>
>
> but the purpose was not a functioning code, but opinions about the api
> and the semantics:
> 1, multiple allocations
> 2, release everything allocated in 1 in one quick function.
>
> i.e. one can alloc as much as one wants but free() frees everything at
> once.
>
>
>
> On 7/1/05, Peter Johansson <Peter.Johansson@xxxxxxxxxxxx> wrote:
>> ronnie sahlberg said:
>> > List
>> >
>> > Attached are two new files with a new FAST api to provide memory
>> > allocation and automatic garbage collection with an allocation
>> > lifetime of
>> > either until-next-packet
>> > or until-next-capture-file
>>
>> I had a quick look at the source and have comments on the function
>> emem_capture_alloc:
>> 1) Why is the size parameter to emem_capture_alloc signed? Why is it
>> *only* 32-bit? Should perhaps size_t be used instead?
>> 2) Why is the size rounded to the nearest higher 4-byte boundary. This
>> assumes a 32-bit platform, right? Why not round to an 8 byte boundary
>> instead to make this work on 64-bit platforms too!?
>>
>> I took the liberty of changing the implementation a bit as can be seen
>> in
>> the attached modified_emem.c file. There I have made changes for my
>> questions in 1) and 2) above as well as rewriting it a bit to be a bit
>> (in
>> my personal oppinion) more generic for future enhancements.
>>
>> Regards, Peter
