This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Mosberger wrote: > I don't see anything that would prevent NPTL from providing better > async-cancel-safety, but juding by your response, it doesn't. Certainly not. Since all this special handling makes the normal case slower. Asynchronous cancellation is bad and fortunately rarely used, so no effort which slows down general code and which is necessary to support async cancel is worth it. > I still don't understand the interaction between signals and > thread-cancellation and I couldn't find where this is being discussed > in the standard. Any pointers? What interaction? Cancellation is implemented via signals. That should be obvious. - -- â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/uXY42ijCOnn/RHQRAqA1AJ44VvAwgqTBZzhBFVUfzNDSROTfkgCfW33k u1Ut+fy8b8x8z6qjoDLGfiA= =ncVK -----END PGP SIGNATURE-----
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |