Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Aug 2010 17:42:18 +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:  <20100819144218.GH2396@deviant.kiev.zoral.com.ua>
In-Reply-To: <4C6D6384.7080506@freebsd.org>
References:  <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> <20100819083809.GC2396@deviant.kiev.zoral.com.ua> <4C6D6384.7080506@freebsd.org>

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

--EZN6irWB3fS+DSGO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> >>>=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 signa=
l,
> >>>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.
> >
>=20
> 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=20
> cancellation request for its user code, POSIX explicitly said EINTR
> should be returned for cancellation.
>=20
> libthr installs a signal handler for signal 32, other threads just
> sends the signal to a target thread which should be canceled, the target=
=20
> 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.
>=20
> 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.
>=20
>=20

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.

--EZN6irWB3fS+DSGO
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iEYEARECAAYFAkxtQskACgkQC3+MBN1Mb4iRAACcC+9YtU4JD4npsDITskt4jsjP
2kUAoMkQ8K5/Mu7xJM4OXV/mNjd5NlON
=/biT
-----END PGP SIGNATURE-----

--EZN6irWB3fS+DSGO--



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