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." > > 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
