On Friday 26 February 2016 08:58:05 EXT Bill Fischofer wrote:
> You can set an odp_queue_t variable to ODP_QUEUE_INVALID as an initial
> value but not as an alternative to odp_queue_destroy(). If you want to
> defer the destroy operation that's fine, however you still need to
remember
> the handle someplace so that it can be used in a subsequent destroy
call to
> release the implementation resources associated with it.
>
> As Bala notes, until these resources are released that may limit the
> ability to do create() calls for other queues.
This is a good point that we might keep in mind.
>
> Note also, that if you want to make a reference to ODP_QUEUE_INVALID
you
> must do so using that designated symbol, not by reaching into whatever
> implementation-specific construct may be behind that symbol. Like any
> other handle, the various ODP_xxx_INVALID handles are opaque and are
> designed to be used as comparators to indicate allocation/create
success or
> failure.
>
> So the following sort of code is perfectly acceptable:
>
> odp_queue_t my_q = ODP_QUEUE_INVALID; // Initialize my_q to
unallocated
> state
>
> ...
>
> if (my_q == ODP_QUEUE_INVALID) // We need to create a queue
> my_q = odp_queue_create(...);
>
> ...
>
> // Destroy my_q and return it to unallocated state
> if (my_q != ODP_QUEUE_INVALID) {
> if (odp_queue_destroy(my_q) == 0)
> my_q = ODP_QUEUE_INVALID;
> else ... // destroy failed (q probably not empty), take some other
> action
> }
In practice, this yields errors when working with an
odp_queue_t defined as an union, unless you define ODP_QUEUE_INVALID
as an _odp_cast_scalar(<value>) which was not recommended.
>
> So if you want to defer queue destruction, simply note that and put the
> handle on a deferred deallocation list someplace.
>
I'm not sure if we want to recreate the queue immediately, so
this housekeeping sounds good, but it doesn't consider the leftovers in
the interface and the generation of the new queue.
Best regards.
José.
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
