kostikbel at gmail.com
Tue Aug 17 10:54:35 UTC 2010
On Tue, Aug 17, 2010 at 09:29:52AM +0000, David Xu wrote:
> Kostik Belousov wrote:
> >On Mon, Aug 16, 2010 at 04:43:02PM +0000, David Xu wrote:
> >>Kostik Belousov wrote:
> >>>On Mon, Aug 16, 2010 at 11:53:52AM +0000, David Xu wrote:
> >>>>Kostik Belousov wrote:
> >>>>>Missed this, thank you for pointing it out. Updated patch is at
> >>>>I found SIGCANCEL is masked by
> >>>>thr_cancel_deferred(THR_CANCEL_DEFERRED_ENABLE), issignal() does not
> >>>>return the masked signal, so how a cancellation point syscall can be
> >>>>interrupted by SIGCANCEL ? I think if a thread being canceled calls
> >>>>msleep(PCATCH), it should find the signal and return EINTR.
> >>>Yes, for EINTR and ERESTART case, the thread should be canceled.
> >>>Please look at the check_cancel() helper that is called at the syscall
> >>>entry and before return. If the check_cancel() decided that the syscall
> >>>is cancellation point and the thread in the deferred cancel mode, and
> >>>EINTR or ERESTART is supplied as error code, then SIGCANCEL is removed
> >>>from the thread signal mask. It is restored in the mask by ast().
> >>I saw your patch has following lines, on syscall entry, if the
> >>check_cancel finds that the syscall is cancellation point and
> >>SIGCANCEL exists, it returns non-zero value, then the real syscall
> >>body at line 319 of subr_trap.c is not executed and prematurely returns.
> >>This is not what I want,as you said the syscall's implementation should
> >>always be executed, and if the thread will be blocked, then it should be
> >>interrupted by existing SIGCANCEL via issignal() which is called by
> >>sleepqueue routines. I think the current patch also has potential
> >No, I do not think what you describe is completely right behaviour.
> >As I understand SUSv4, the deferred cancel behaviour should be
> >as following:
> >- when we reach cancellation point with cancel already pending,
> > the syscall should not be executed at all, cancel happens and
> > cleanup handlers executed before thread exiting.
> >- when we reach cancellation point without cancel pending, and syscall
> > goes to sleep, and cancellation request arrives during the sleep,
> > again the syscall should be aborted, and cancellation happens.
> so what's the problem with current libthr code ? it already did above
> in this way.
> using close() as an example, what does your modification gains ?
The thread in the deferred cancellation mode currently is also
cancelled after close() (or write() or any other cancel-point syscall)
returned without being interrupted. The window is between syscall
starts syscall return sequence in the kernel and up to the point when
_thr_cancel_leave() is executed by syscall wrapper in libthr.
My reading of both SUSv4 and Solaris cancellation(5) page is that
this is wrong. I described this is my first message that started the
thread. Patch prevents cancellation after syscall is executed successfully
but before libthr has a chance to mark thread as not executing the
> is the kern_close() always executed for close() syscall?
> or if the cancellation is already pending and the syscall prematurely
> returns, will the file descriptor be leaked ? if it is leaked, then
> your modification is not better than current libthr code, it is even
> worse than current one, because your code involves kernel.
Close() issue pointed out by Jilles, where kernel ignores error from
close fop and always clears fd, is different from this. My point
is also valid for other syscalls with externally observable side-effects,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20100817/b894ed72/attachment.pgp
More information about the freebsd-threads