PTHREAD_CANCEL_DEFERRED

[Kostik Belousov]

On Thu, Aug 19, 2010 at 05:01:56PM +0000, David Xu wrote:
> 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.
> 
> 

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20100819/7f28406b/attachment.pgp