Re: [lng-odp] [PATCH] validation: odp_pool: add double destroy

[Bill Fischofer]

Good points.  I agree it's better to leave this behavior undefined.

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, &params);
>> +       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
>

_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp