From owner-freebsd-threads@FreeBSD.ORG Thu Aug 19 08:38:17 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 C13C51065679; Thu, 19 Aug 2010 08:38:17 +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 5A5268FC08; Thu, 19 Aug 2010 08:38:16 +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 o7J8c9aJ018810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 11:38:09 +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 o7J8c95v023065; Thu, 19 Aug 2010 11:38:09 +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 o7J8c9PG023064; Thu, 19 Aug 2010 11:38:09 +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: Thu, 19 Aug 2010 11:38:09 +0300 From: Kostik Belousov To: David Xu Message-ID: <20100819083809.GC2396@deviant.kiev.zoral.com.ua> References: <4C65E0FE.2030803@freebsd.org> <20100814144715.GB2396@deviant.kiev.zoral.com.ua> <4C6926D0.2020909@freebsd.org> <20100816082022.GO2396@deviant.kiev.zoral.com.ua> <4C696A96.7020709@freebsd.org> <20100816104303.GP2396@deviant.kiev.zoral.com.ua> <4C6AA092.40708@freebsd.org> <4C6BE0F7.10207@freebsd.org> <20100818100403.GS2396@deviant.kiev.zoral.com.ua> <4C6C6184.9030602@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+8CbEAItL+VIz8WN" Content-Disposition: inline In-Reply-To: <4C6C6184.9030602@freebsd.org> 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 Cc: freebsd-threads@freebsd.org Subject: Re: 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: Thu, 19 Aug 2010 08:38:17 -0000 --+8CbEAItL+VIz8WN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 19, 2010 at 06:41:08AM +0800, David Xu wrote: > Kostik Belousov wrote: > >On Wed, Aug 18, 2010 at 01:32:39PM +0000, David Xu wrote: > > =20 > >>David Xu wrote: > >> =20 > >>>My idea is to always let close() syscall run, until it will be > >>>blocked by lower layer, e.g tty or socket layer, as manual of close() > >>>said it always release the file descriptor despite whether > >>>it returns EINTR or EWOULDBLOCK, when it is going to sleep, > >>>a flag will cause it to abort the sleep. > >>>if the thread does not found the flag at that time, > >>>a latter signal SIGCANCEL sent by pthread_cancel will unblock it, > >>>this is how signal works. > >>> > >>> =20 > >>I have worked out a patch: > >>http://people.freebsd.org/~davidxu/patch/thread_cancel.patch > >> > >> =20 > >Ok, the patch is definitely better then my proposal. But it has several > >details that seems to need correction. > > > >First, if TDP_WAKEUP-marked thread receives any non-cancellation signal, > >then a syscall returns with EINTR. This breaks SA_RESTART. > > > > =20 > I don't think it breaks SA_RESTART, there are reasons this is allowed: I think I need to be more verbose. What I am saying is that if the posted signal is not SIGCANCEL, then the sleepq_catch_signal() change does two things wrong, IMO: 1. it will return EINTR while the signal marked as SA_RESTART interrupted restartable syscall. 2. TDP_WAKEUP should not be cleared for this case, since we should still be prepared for special handling of SIGCANCEL, if it arrives. In other words, I propose to clear TDP_WAKEUP only when the posted=20 signal is SIGCANCEL. > 1) POSIX explicitly specifies that the EINTR should be returned: > =20 > http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_09.html >=20 > I copied it here: > The side effects of acting upon a cancellation request while=20 > suspended during a call > of a function are the same as the side effects that may be seen in a=20 > single-threaded > program when a call to a function is interrupted by a signal and the=20 > given function > returns [EINTR]. Any such side effects occur before any cancellation=20 > cleanup > handlers are called. >=20 > 2) Traditional UNIX signal does not delivered in queued order, for exampl= e, > BSD delivers signal from lowest number to highest, like issignal() doe= s, > it only returns lowest number signal which is not masked. a later sign= al > may be delivered first because it has lower number. so if a lower=20 > number > signal returns EINTR, but a higher signal returns ERESTART, the=20 > final result > still is EINTR. >=20 > 3) Some system calls are not restartable, it always return EINTR when=20 > interrupted > by signal. >=20 > 4) Most of program already prepared for EINTR, it is seldom to find a=20 > program > does not consider EINTR. >=20 > >Also, I think that a condition to perform cancellation in thr_syscalls.c > >should be not (ret =3D=3D -1), but (ret =3D=3D -1 && errno =3D=3D EINTR). > > =20 > Yes, you are right, errno may be checked. --+8CbEAItL+VIz8WN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxs7XAACgkQC3+MBN1Mb4gFSQCeNZv1XAFeZmGcRZe1r5mfvV6A RPgAoKiW0+Pz9YcjijiPBFLMAuGXetVz =EDPi -----END PGP SIGNATURE----- --+8CbEAItL+VIz8WN--