On 22 April 2015 at 06:44, 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? Yes I think it could be if you delete a bad pool. This test arose more specifically to stress the error leg of this function using only the public API - our validation does very little to quantify what is permissible beyond very optimistic cases, and in part to clarify the behavior in the docs when you do try to do those other things. Do we have it documented somewhere? > Not yet but I want it to be. If the test goes in then we can add the specific case that deleted a destroyed pool returns an error, if not we can document that it is undefined. I assume behavior should be undefined in this case. After pool is > destroyed its handle can't be used anymore. > We need to document that in words that that is the case. > > 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. > -- 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
