diff options
author | Niels de Vos <ndevos@redhat.com> | 2017-07-14 18:35:10 +0200 |
---|---|---|
committer | Jeff Darcy <jeff@pl.atyp.us> | 2017-07-19 20:18:24 +0000 |
commit | 1e8e6264033669332d4cfa117faf678d7631a7b1 (patch) | |
tree | a58c0b819e26810c60bea2354cfa8eb14f1cf26a /extras/test/stop_glusterd.sh | |
parent | acdbdaeba222e9ffeae077485681e5101c48d107 (diff) |
mem-pool: initialize pthread_key_t pool_key in mem_pool_init_early()
It is not possible to call pthread_key_delete for the pool_key that is
intialized in the constructor for the memory pools. This makes it
difficult to do a full cleanup of all the resources in mem_pools_fini().
For this, the initialization of pool_key should be moved to
mem_pool_init().
However, the glusterfsd binary has a rather complex initialization
procedure. The memory pools need to get initialized partially to get
mem_get() functionality working. But, the pool_sweeper thread can get
killed in case it is started before glusterfsd deamonizes.
In order to solve this, mem_pools_init() is split into two pieces:
1. mem_pools_init_early() for initializing the basic structures
2. mem_pools_init_late() to start the pool_sweeper thread
With the split of mem_pools_init(), and placing the pthread_key_create()
in mem_pools_init_early(), it is now possible to correctly cleanup the
pool_key with pthread_key_delete() in mem_pools_fini().
It seems that there was no memory pool initialization in the CLI. This
has been added as well now. Without it, the CLI will not be able to call
mem_get() successfully which results in a hang of the process.
Change-Id: I1de0153dfe600fd79eac7468cc070e4bd35e71dd
BUG: 1470170
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: https://review.gluster.org/17779
Smoke: Gluster Build System <jenkins@build.gluster.org>
CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
Diffstat (limited to 'extras/test/stop_glusterd.sh')
0 files changed, 0 insertions, 0 deletions