>
> So to summarize, the possible approaches are:
>> 1. Stealing from client-malloc; fluid will call free(). Won't work with
>> different allocators other than malloc.
>> 2. Stealing from client-fluid_alloc; fluid will call fluid_free(). At
>> least it lets fluid control the allocator.
>> 3. Borrowing; fluid will not free memory. Requires complicated memory
>> management in the client.
>> 4. Borrowing, with a "destructor" callback. Lets the client control
>> allocation and freeing, and can easily simulate #1 or #2.
>> 5. Copying. Client must free, but can do it right away. Easiest method,
>> but inefficient.
>>
>
> Good summary. I think the reason I thought of 5 as the most flexible one
> would be because if we ever changed it to do the parsing at add_mem time, we
> would just skip the copy, and no additional memory management would be
> necessary.
>
Oh I see. Well if we went with #2 it would still be easy to extend it to do
parsing at "add time"; we would just make it free the memory immediately.
The only problem is it would now be inefficient if a client *did* do a copy.
Also the interface ("it reads from the buffer then frees the buffer for some
reason") would no longer make much sense. But it wouldn't break clients, at
least.
I suppose the question is then, is there a serious intent (not now, but in
the future) to modify the behaviour so it parses the MIDI file at "add
time"? If so, #5 makes the most sense. If not, I think #2 still makes the
most sense.
Note that initially your concern was about having multiple MIDI files in
memory at a time (which is why you suggested the compromise of still storing
filenames at "add time" until "play time" when the full load-and-parse is
done). It's probably not too big of a concern given that I've never seen a
MIDI file above 1MB, but something to consider.
The decision won't really affect the implementation (we can easily change
garbage collection strategies after this patch has been written), it's just
something we need to decide on before committing to the trunk, as it will
affect the clients.
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
