From owner-freebsd-threads@FreeBSD.ORG Wed Aug 11 21:19:29 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1893F106566C for ; Wed, 11 Aug 2010 21:19:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A95C18FC12 for ; Wed, 11 Aug 2010 21:19:28 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7BKlw4r049940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Aug 2010 23:47:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7BKlw6i097703 for ; Wed, 11 Aug 2010 23:47:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7BKlwYk097702 for freebsd-threads@freebsd.org; Wed, 11 Aug 2010 23:47:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Aug 2010 23:47:58 +0300 From: Kostik Belousov To: freebsd-threads@freebsd.org Message-ID: <20100811204758.GQ2396@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wwtQuX191/I956S7" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Subject: PTHREAD_CANCEL_DEFERRED X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 21:19:29 -0000 --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--