On 22 April 2015 at 13:29, Mike Holmes <[email protected]> wrote:
> > > On 22 April 2015 at 07:26, Bill Fischofer <[email protected]> > 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." > "Attempting to delete an already deleted resource results in unspecified behavior." > > >> >> On Wed, Apr 22, 2015 at 5:44 AM, Taras Kondratiuk < >> [email protected]> wrote: >> >>> On 04/21/2015 10:14 PM, Mike Holmes wrote: >>> >>>> Signed-off-by: Mike Holmes <[email protected]> >>>> --- >>>> 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 >>> [email protected] >>> 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 > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
