Date: Fri, 13 Aug 2010 09:23:51 +0000 From: David Xu <davidxu@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-threads@freebsd.org Subject: Re: PTHREAD_CANCEL_DEFERRED Message-ID: <4C650F27.1000305@freebsd.org> In-Reply-To: <4C650D0F.9060905@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>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: >>> 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. > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C650F27.1000305>