An improper locking bug on the lock iv_wait_lock

[ycaibb]

Hi developers, in the below codes, the lock iv_wait_lock could be not released before program's exit. I think it is better to write unlock ___mutex_unlock(&iv_wait_lock); before the exit exit(1); for better resource management and code symmetry.

ivykis/src/iv_wait.c

Lines 291 to 309 in f1b1455

	___mutex_lock(&iv_wait_lock);
	pid = fork();
	if (pid < 0) {
	___mutex_unlock(&iv_wait_lock);
	__iv_wait_interest_unregister(tinfo, this);
	return pid;
	}
	if (pid == 0) {
	iv_signal_child_reset_postfork();
	fn(cookie);
	exit(1);
	} else {
	this->pid = pid;
	iv_avl_tree_insert(&iv_wait_interests, &this->avl_node);
	}
	___mutex_unlock(&iv_wait_lock);

[buytenh]

Hello! Thank you for your comment.

In the if (pid == 0) { block, we are in the child process that is created by fork(), and the child process will have a copy-on-write copy of all of the parent's memory areas, including of iv_wait_lock, and freeing that lock here will actually do nothing -- in particular, it will not free the lock in the parent process.

Also, the fn(cookie); call typically does not return -- see for example how src/iv_popen.c or test.mt/iv_wait_test.c use iv_wait_interest_register_spawn() -- and the exit(1); call is here only as a safeguard in case the fn(cookie); call accidentally does return.

In other words, the fact that the child process does not explicitly free iv_wait_lock is intended. :)

[ycaibb]

@buytenh Thank you very much for your detailed reply!!