Date: Fri, 13 Aug 2010 17:14:02 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: PTHREAD_CANCEL_DEFERRED Message-ID: <20100813141402.GW2396@deviant.kiev.zoral.com.ua> In-Reply-To: <4C650F27.1000305@freebsd.org> References: <20100811204758.GQ2396@deviant.kiev.zoral.com.ua> <4C63D42D.8040606@freebsd.org> <20100812083006.GR2396@deviant.kiev.zoral.com.ua> <4C642E9B.8000300@freebsd.org> <20100812093353.GS2396@deviant.kiev.zoral.com.ua> <4C650D0F.9060905@freebsd.org> <4C650F27.1000305@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--wYXww9TlNKyqAMAe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 13, 2010 at 09:23:51AM +0000, David Xu wrote: > David Xu wrote: >=20 > >>>if you don't call testcancel() in close() stub like current libthr did, > >>>B won't response to the cancel request, you lost the race. > >>This situation should be handled by my proposal, since SIGCANCEL is > >>delivered only > >>- at the syscall entry point > >>- at the syscall premature return > >>Userspace would not get SIGCANCEL at time of [1], instead, signal will > >>be delivered at [2]. > >kernel may don't know if the syscall is cancelable, because it depends > >on usage, if the close() syscall is used by fclose(), then the syscall > >is not cancellation point, libc avoids this by using _close(), > >and libthr does not override it. if kernel knows when a thread is at > >cancellation point, then it needs another syscall to set and unset > >the flag, but that's too expensive and in practical it is not > >acceptable. The kernel only decides whether to process SIGCANCEL specially. The decision about the cancel point is still at the hands of the threading library. The delivered SIGCANCEL goes through the same checks of eligibility for cancellation as before. But it is only delivered now at potential cancellation points for deferred case. Please see the patch at http://people.freebsd.org/~kib//misc/cancel_defer.1.patch for the proof of concept prototype. > > > a bit out of topic, I also think that thread cancellation is not > better than a simple signal, because it does not return to caller > and force you to push and pop somethings, it may also be incompatible > with some language's exception handling, why does not just use > signal to interrupt syscall and let caller to check if the thread > should exit, the UNIX is quite good at this. This still does not give the answer of whether the syscall was executed. I have to check for %pc to see when the signal was delivered. Also, to be able to use signal in the way you suggested, I need a signal handler installed. This is very inconvenient from the library. BTW, I looked at the Solaris cancellation(5) man page, and it seems that Solaris implements the proper (from my POV) deferred cancellation: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When cancellation is deferred (the default case), cancellation occurs only within the scope of a function defined as a cancellation point (after the function is called and before the function returns). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --wYXww9TlNKyqAMAe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxlUykACgkQC3+MBN1Mb4gO2gCgpTwyqghw1i+OasAHe6sMQttX 7sIAoJR61UxpeivMZl0I/LKwTAMtoNd8 =X3zg -----END PGP SIGNATURE----- --wYXww9TlNKyqAMAe--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100813141402.GW2396>