Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Aug 2010 11:38:09 +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:  <20100819083809.GC2396@deviant.kiev.zoral.com.ua>
In-Reply-To: <4C6C6184.9030602@freebsd.org>
References:  <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> <4C6AA092.40708@freebsd.org> <4C6BE0F7.10207@freebsd.org> <20100818100403.GS2396@deviant.kiev.zoral.com.ua> <4C6C6184.9030602@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--+8CbEAItL+VIz8WN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> > =20
> >>David Xu wrote:
> >>   =20
> >>>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.
> >>>
> >>>     =20
> >>I have worked out a patch:
> >>http://people.freebsd.org/~davidxu/patch/thread_cancel.patch
> >>
> >>   =20
> >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.
> >
> > =20
> 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=20
signal is SIGCANCEL.

> 1) POSIX explicitly specifies that the EINTR should be returned:
>   =20
> http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_09.html
>=20
>    I copied it here:
>   The side effects of acting upon a cancellation request while=20
> suspended during a call
>   of a function are the same as the side effects that may be seen in a=20
> single-threaded
>   program when a call to a function is interrupted by a signal and the=20
> given function
>   returns [EINTR]. Any such side effects occur before any cancellation=20
> cleanup
>   handlers are called.
>=20
> 2) Traditional UNIX signal does not delivered in queued order, for exampl=
e,
>    BSD delivers signal from lowest number to highest, like issignal() doe=
s,
>    it only returns lowest number signal which is not masked. a later sign=
al
>    may be delivered first because it has lower number.  so if a lower=20
> number
>    signal returns EINTR, but a higher signal returns ERESTART, the=20
> final result
>    still is EINTR.
>=20
> 3) Some system calls are not restartable, it always return EINTR when=20
> interrupted
>    by signal.
>=20
> 4) Most of program already prepared for EINTR, it is seldom to find a=20
> program
>    does not consider EINTR.
>=20
> >Also, I think that a condition to perform cancellation in thr_syscalls.c
> >should be not (ret =3D=3D -1), but (ret =3D=3D -1 && errno =3D=3D EINTR).
> > =20
> Yes, you are right, errno may be checked.

--+8CbEAItL+VIz8WN
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAkxs7XAACgkQC3+MBN1Mb4gFSQCeNZv1XAFeZmGcRZe1r5mfvV6A
RPgAoKiW0+Pz9YcjijiPBFLMAuGXetVz
=EDPi
-----END PGP SIGNATURE-----

--+8CbEAItL+VIz8WN--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100819083809.GC2396>