PTHREAD_CANCEL_DEFERRED
Kostik Belousov
kostikbel at gmail.com
Thu Aug 19 08:38:17 UTC 2010
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.
> 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.
-------------- 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/c05c49e9/attachment.pgp
More information about the freebsd-threads
mailing list