Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Aug 2010 23:47:58 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        freebsd-threads@freebsd.org
Subject:   PTHREAD_CANCEL_DEFERRED
Message-ID:  <20100811204758.GQ2396@deviant.kiev.zoral.com.ua>

next in thread | raw e-mail | index | archive | help

--wwtQuX191/I956S7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,
Let consider the thread in the state where the cancelation is enabled
and cancelation mode set to the PTHREAD_CANCEL_DEFERRED.

SUSv4 says the following:
Whenever a thread has cancelability enabled and a cancellation request
has been made with that thread as the target, and the thread then
calls any function that is a cancellation point (such as
pthread_testcancel() or read()), the cancellation request shall be
acted upon before the function returns. If a thread has cancelability
enabled and a cancellation request is made with the thread as a target
while the thread is suspended at a cancellation point, the thread
shall be awakened and the cancellation request shall be acted upon.

Take the close(2) as example, and assume that the cancel is enabled
for the thread in deferred mode. libthr wrapper around the syscall
executes this:

     	curthread->cancel_point++;
	testcancel(curthread);
	__sys_close(fd);
	curthread->cancel_point--;

The pthread_cancel() sends the SIGCANCEL signal to the
thread. SIGCANCEL handler calls pthread_exit() if thread has the
cancel_point greater then 0.

I think this is not right. For instance, thread can be canceled due to
SIGCANCEL delivery at the point after the return into the usermode
from close(), but before cancel_point is decremented. IMO, the cited
statements from the SUSv4 prohibit such behaviour. We should cancel
either before closing fd, or during the sleep in close(), but then the
syscall should be aborted ("as if signal is delivered"), and again fd
should not be closed.

Actually, besides not being compliant, I think that the current
behaviour is not useful, since in deferred case, we cannot know
whether the action by the call that is cancelation point was performed
or not.

This is not a rant, I probably will fix the issue if it is agreed
upon. Opinions ?

--wwtQuX191/I956S7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAkxjDH0ACgkQC3+MBN1Mb4ibaQCfRzmKgUwxbaIyWxwnGeL7qlX4
ZdwAoOoEdCqsQcxeWK0FelHXInamXgma
=nLnJ
-----END PGP SIGNATURE-----

--wwtQuX191/I956S7--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100811204758.GQ2396>