From owner-freebsd-threads@FreeBSD.ORG Thu Aug 19 09:01:58 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 1933F1065696 for ; Thu, 19 Aug 2010 09:01:58 +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 DCE4F8FC28; Thu, 19 Aug 2010 09:01:57 +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 o7J91tVW094575; Thu, 19 Aug 2010 09:01:56 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4C6D6384.7080506@freebsd.org> Date: Thu, 19 Aug 2010 17:01:56 +0000 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: Kostik Belousov 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> <20100819083809.GC2396@deviant.kiev.zoral.com.ua> In-Reply-To: <20100819083809.GC2396@deviant.kiev.zoral.com.ua> 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: Thu, 19 Aug 2010 09:01:58 -0000 Kostik Belousov wrote: > 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: >>> >>>> David Xu wrote: >>>> >>>>> 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. >>>>> >>>>> >>>> I have worked out a patch: >>>> http://people.freebsd.org/~davidxu/patch/thread_cancel.patch >>>> >>>> >>> 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. >>> >>> >> 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 > signal is SIGCANCEL. > TDP_WAKEUP is only set by the current thread itself, it is unrelated to any signal, it is that current libthr library code is acting upon the cancellation request for its user code, POSIX explicitly said EINTR should be returned for cancellation. libthr installs a signal handler for signal 32, other threads just sends the signal to a target thread which should be canceled, the target thread than sets TDP_WAKEUP for itself in signal 32 handler, it is used to unblock next syscall which is a cancellation point from pthread view. SIGCANCEL should not be treated specially by kernel, kernel should not know it is a pthread application, non-threaded application should use signal 32 without any side effect. Having a pthread knowledge in kernel is crappy, no kernel function should know there is a concept called cancellation point.