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
