Date: Thu, 19 Aug 2010 06:41:08 +0800 From: David Xu <davidxu@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-threads@freebsd.org Subject: Re: PTHREAD_CANCEL_DEFERRED Message-ID: <4C6C6184.9030602@freebsd.org> In-Reply-To: <20100818100403.GS2396@deviant.kiev.zoral.com.ua> References: <4C650F27.1000305@freebsd.org> <20100813141402.GW2396@deviant.kiev.zoral.com.ua> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: 1) POSIX explicitly specifies that the EINTR should be returned: http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_09.html I copied it here: The side effects of acting upon a cancellation request while suspended during a call of a function are the same as the side effects that may be seen in a single-threaded program when a call to a function is interrupted by a signal and the given function returns [EINTR]. Any such side effects occur before any cancellation cleanup handlers are called. 2) Traditional UNIX signal does not delivered in queued order, for example, BSD delivers signal from lowest number to highest, like issignal() does, it only returns lowest number signal which is not masked. a later signal may be delivered first because it has lower number. so if a lower number signal returns EINTR, but a higher signal returns ERESTART, the final result still is EINTR. 3) Some system calls are not restartable, it always return EINTR when interrupted by signal. 4) Most of program already prepared for EINTR, it is seldom to find a program does not consider EINTR. > Also, I think that a condition to perform cancellation in thr_syscalls.c > should be not (ret == -1), but (ret == -1 && errno == EINTR). > Yes, you are right, errno may be checked.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C6C6184.9030602>