We just need to be specific about what we're testing here. This really is
no different than attempting to free a memory area twice. Clearly an
error, but do we require an implementation to detect and report this or is
it an application responsibility?
Taras' point about race conditions in multithreaded apps is a good one.
While this specific test is single-threaded, that's not going to be the
case for most ODP applications. Perhaps things like this are better
detected by tools like coverity?
On Wed, Apr 22, 2015 at 6:29 AM, Mike Holmes <mike.hol...@linaro.org> wrote:
>
>
> On 22 April 2015 at 07:26, Bill Fischofer <bill.fischo...@linaro.org>
> wrote:
>
>> Good points. I agree it's better to leave this behavior undefined.
>>
>
> If that is consensus I will send a patch for the docs to add.
>
> "Deleting an already deleted pool results in unspecified behavior."
>
>
>>
>> On Wed, Apr 22, 2015 at 5:44 AM, Taras Kondratiuk <
>> taras.kondrat...@linaro.org> wrote:
>>
>>> On 04/21/2015 10:14 PM, Mike Holmes wrote:
>>>
>>>> Signed-off-by: Mike Holmes <mike.hol...@linaro.org>
>>>> ---
>>>> test/validation/odp_pool.c | 25 +++++++++++++++++++++++++
>>>> 1 file changed, 25 insertions(+)
>>>>
>>>> diff --git a/test/validation/odp_pool.c b/test/validation/odp_pool.c
>>>> index 1a518a0..c2f9a1b 100644
>>>> --- a/test/validation/odp_pool.c
>>>> +++ b/test/validation/odp_pool.c
>>>> @@ -11,6 +11,30 @@ static int pool_name_number = 1;
>>>> static const int default_buffer_size = 1500;
>>>> static const int default_buffer_num = 1000;
>>>>
>>>> +static void pool_double_destroy(void)
>>>> +{
>>>> + odp_pool_param_t params = {
>>>> + .buf = {
>>>> + .size = default_buffer_size,
>>>> + .align = ODP_CACHE_LINE_SIZE,
>>>> + .num = default_buffer_num,
>>>> + },
>>>> + .type = ODP_POOL_BUFFER,
>>>> + };
>>>> + odp_pool_t pool;
>>>> + char pool_name[ODP_POOL_NAME_LEN];
>>>> +
>>>> + snprintf(pool_name, sizeof(pool_name),
>>>> + "test_pool-%d", pool_name_number++);
>>>> +
>>>> + pool = odp_pool_create(pool_name, ODP_SHM_INVALID, ¶ms);
>>>> + CU_ASSERT_FATAL(pool != ODP_POOL_INVALID);
>>>> + CU_ASSERT(odp_pool_to_u64(pool) !=
>>>> + odp_pool_to_u64(ODP_POOL_INVALID));
>>>> + CU_ASSERT(odp_pool_destroy(pool) == 0);
>>>> + CU_ASSERT(odp_pool_destroy(pool) < 0);
>>>>
>>>
>>> Is this an expected behavior? Do we have it documented somewhere?
>>> I assume behavior should be undefined in this case. After pool is
>>> destroyed its handle can't be used anymore.
>>>
>>> This test is single-threaded, but assume that there is another thread
>>> which created a pool with the same odp_pool_t handle just between
>>> two odp_pool_destroy(pool) calls. A second odp_pool_destroy() will
>>> destroy a new pool and return 0.
>>> If you demand this behavior, then you effectively force implementation
>>> to use generation-tagged handles.
>>>
>>> _______________________________________________
>>> lng-odp mailing list
>>> lng-odp@lists.linaro.org
>>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>>
>>
>>
>
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
>
>
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
