Re: [PATCH] thread cancellation via C++ exception

--===============0753264086==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg"
Content-Disposition: inline


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

Scott Lamb <[email protected]> writes:
=20
> A couple questions:
>=20
> 1) Can it be caught and rethrown?

Yes but can't finalize it (in other words the catch block should exit=20
via `throw;').

> I read an earlier thread in which someone mentioned using =20
> boost::python. He wanted to catch the cancellation, throw an equivalent =
=20
> Python exception, and rethrow the C++ exception at the other end. This=20
> is not allowed currently in NPTL.

Right, it is not allowed with my patch either. I agree it would be nice
to allow 'native' exceptions to propagate through corresponding parts
of call stack. It is not clear, however, how to detect 'cancellation=20
refusal' in such cases.=20

> I'd like to be able to do something similar with C code that is not =20
> cancellation-safe. OpenSSL, for example. It would be prohibitively =20
> difficult to modify these libraries to use cancellation and get the =20
> patches integrated upstream, but much easier to propogate a C error =20
> code through then rethrow the exception at the other end. No changes to =
=20
> the C code would then be required.

Same problem - no way to enforce cancellation.


> 2) What happens if the thread is canceled while a C++ exception is =20
> already active?

terminate() will be called.

> Unless my test is flawed (it's at  =20
> <http://www.slamb.org/svn/repos/projects/cancellation_tests/=20
> test_cancellation_while_throwing.cc>) or NPTL's behavior has changed =20
> since the version I tested, it will abort with "terminate called =20
> without an active exception".=20

With my patch it prints

terminate called after throwing a `(anonymous namespace)::pthread_canceled'
  what(): N37_GLOBAL__N__ZNSt15thread_canceledD2Ev16pthread_canceledE
Aborted

which is what's expected.


> I think the ideal behavior would be to defer the cancellation until=20
> the exception is handled.

Well, you can do it already in your dtor: if you are going to call
a cancellation point from your dtor (close() comes to mind) then
disable cancellation.

=20
> I probably wouldn't use it, even if your patch allowed me to do these =20
> things. I've given up on pthread cancellation, due to bugs and the lack =
=20
> of standardization w.r.t. C++. This new behavior might be helpful for =20
> code intended to run solely under that environment, but for portable =20
> code new behaviors can only make things worse.

I stopped worrying about portability and feel noticeably better now ;-)


> Instead, I'm working on implementing my own thing on top of my sigsafe =
=20
> library. None of the standard library functions will be cancellation =20
> points to my code (just sigsafe_XXX() system call wrappers and code =20
> that uses them), but that's life.

Are they still going to be cancellation points? For example, if I=20
call your sigsafe_mutex_lock() and then cancel this thread (perhaps
through sigsafe_cancel()) will it still work? Note that according to=20
the SUS pthread_mutex_lock "shall not return an error code of [EINTR]".


hth,
-boris

--gKMricLos+KVdGMg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iQGVAwUBQKkvEMiAKQuuCE8dAQLz4wwAx1AcUFwHQlNFvkaO3mYJc7g7IosgXwd3
7tDH528cW25bvzZ8pTDMg1yJ5GVcnSVZexlDdaHz4OLGU9cObTCGxhb28yA5thii
dVTBdt52qFGd+GpTJzXDycvlqOdhXgLf9Ks7J6UnZEJBdXNBTLz+A5Y4AGlbBGjd
/aKcbBQ0LYfuJNmGlWL+nZx7I8Uum8BJO/0r3MBSbku8WriQzenC66vGRYmwEI2W
c48CQyffuy6ZL7vJDAc8fAnElH7JBw7ivPpeYRmFUXasa+UEBdsDv1SjuQ4iewwG
KZ+05SdtJOL4PBp8svMYKzjq+h6+U3r3W1z5yjeT5lrw0SAnSB1sYQPs8KfBJlOH
h3jgFf0mqVehMk23RLGpgu8SFQwgEGkfs2jpQ4xSHzOvX1bwOfdxBuaE1MIZXgN8
6+BJ7FM62N1PnMjZizmQ7MKUcK+EBhxKM1OcQSIcNSR+QixXBEFOC6AMZCOX7P3H
NfDZdN0UtVe/J6rSoCOzdQx5wcpvpS12
=Cwo0
-----END PGP SIGNATURE-----

--gKMricLos+KVdGMg--



--===============0753264086==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline