davidxu at freebsd.org
Thu Aug 19 09:01:58 UTC 2010
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:
>>> 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
More information about the freebsd-threads