From owner-freebsd-threads@FreeBSD.ORG Fri Aug 13 01:23:52 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 5E9031065679 for ; Fri, 13 Aug 2010 01:23:52 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF078FC08; Fri, 13 Aug 2010 01:23:52 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o7D1NoAT090889; Fri, 13 Aug 2010 01:23:51 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4C650F27.1000305@freebsd.org> Date: Fri, 13 Aug 2010 09:23:51 +0000 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: Kostik Belousov 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> In-Reply-To: <4C650D0F.9060905@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 13 Aug 2010 01:23:52 -0000 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.