Date: Tue, 17 Aug 2010 13:54:30 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: PTHREAD_CANCEL_DEFERRED Message-ID: <20100817105430.GE2396@deviant.kiev.zoral.com.ua> In-Reply-To: <4C6A5690.6060000@freebsd.org> References: <4C650D0F.9060905@freebsd.org> <4C650F27.1000305@freebsd.org> <20100813141402.GW2396@deviant.kiev.zoral.com.ua> <4C65E0FE.2030803@freebsd.org> <20100814144715.GB2396@deviant.kiev.zoral.com.ua> <4C6926D0.2020909@freebsd.org> <20100816082022.GO2396@deviant.kiev.zoral.com.ua> <4C696A96.7020709@freebsd.org> <20100816104303.GP2396@deviant.kiev.zoral.com.ua> <4C6A5690.6060000@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--fzoBs0edN2XpEQF6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 > >>>>>http://people.freebsd.org/~kib//misc/cancel_defer.2.patch > >>>>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=20 > >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. > > >=20 > 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 cancellation point. > is the kern_close() always executed for close() syscall? > or if the cancellation is already pending and the syscall prematurely=20 > 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, like write(). --fzoBs0edN2XpEQF6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxqamYACgkQC3+MBN1Mb4gBygCgmOBoTa/JjDS77m5YW4fmbx/Y 89AAoJvvNx6Veqcl/+PnL4ZVFBo/sKF6 =RyFR -----END PGP SIGNATURE----- --fzoBs0edN2XpEQF6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100817105430.GE2396>