toggle quoted messageShow quoted text
Personally I would be inclined towards the addition of wombatQueue_deallocate, and then having this called within the context of the existing wombatQueue_destroy. This would result in no change to behaviour for current client applications (destroy would free the memory as it currently does, so a separate call to deallocate would not be needed), but would allow applications to clean up memory where the allocate has succeeded but create has failed (as in your example).
On Tue, Oct 28, 2014 at 2:36 PM, Sam Wilson <Sam.Wilson@...>
I'm just getting around to looking at this now. Would you prefer a patch that adds
, or one that merges both wombatQueue_allocate
and makes wombatQueue_create
a dummy function?
The advantage of the first option is that the API works more like it was intended, but it will break any current users of wombat queues.
The second option retains backward compatibility, but you end up losing the benefits of having separate allocate/create functions.
On 14-09-03 05:34 AM, Damian Maguire wrote:
Unfortunately this is a weakness in the API for the Wombat Queue implementation - it really should have a wombatQueue_deallocate, but it isn't presently available. If you'd like to raise an issue in bugzilla (bugs.openmama.org
we can look at getting it added. Better yet, we'd be happy to accept a patch which addresses the issue in the queue.