Date: Fri, 20 Aug 2010 01:14:55 +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: <4C6DD70F.5070803@freebsd.org> In-Reply-To: <20100819144218.GH2396@deviant.kiev.zoral.com.ua> References: <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> <4C6D6384.7080506@freebsd.org> <20100819144218.GH2396@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov wrote: > > What would happen in the following situation: > thr_wake() is called; > some syscall is started executing and slept, assume that SA_RESTART is > for SIGHUP (just an example); > SIGHUP is sent to the process and the thread is selected > for delivery, also assume that handler is installed. > > As I understand, in this situation, EINTR is returned from syscall. Yes, because cancellation should have higher priority over signals, if signal always causes ERESTART to be returned, and system call is always restarted, the system call may not return forever because its event it is waiting never happens, for example, it is reading a byte from a socket, but it is never available, we end up not being able to cancel the thread, this is incorrect.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C6DD70F.5070803>