From: Loic Domaigne <tech-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org>
To: Michael Kerrisk <mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
josv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
Bert Wesarg <bert.wesarg-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>,
Karsten Weiss
<K.Weiss-Pt+Xe7GJXK+P2YhJcF5u+nqWYbMAw+HU@public.gmane.org>
Subject: Re: For review: pthread_cancel.3
Date: Sat, 22 Nov 2008 07:52:32 +0100 [thread overview]
Message-ID: <4927AC30.6030107@domaigne.com> (raw)
In-Reply-To: <4922C93D.1010804-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Gidday Michael,
>>> Asynchronous cancelability
>>> means that the thread can be canceled at any time
>>> (usually immediately, but the system does not guarantee this).
>>> Deferred cancelability means that cancellation will be delayed until
>>> the thread next calls a function that is a
>>> .IR "cancellation point" .
>>> A list of functions that are or may be cancellation points is
>>> provided in
>>> .IR pthreads (7).
>>
>> It is very important to document the list of functions that are/are
>> not CP in the "may be a CP" list: this is system specific and belongs
>> to the system documentation.
>
> For man-pages-3.14, I have added POSIX.1's lists of "are" and "may be"
> cancellation points to pthreads.7.
>
> However, it unclear to me how one determines the list of functions
> that are cancellation points under glibc. Do you have some ideas
> about this?
I checked out, and I found no obvious to extract the information
automatically from the source. We may have to ask support from the Glibc
folks.
>>> .SH NOTES
>>> On Linux, cancellation is implemented using signals.
>>> Under the NPTL threading implementation,
>>> the first real-time signal (i.e., signal 32) is used for this purpose.
>>
>> Hmmm... You are right: NPTL uses the first real-time signal (32)
>> provided by the *kernel*. As a matter of fact, Glibc reserves kernel
>> real-time signals 32 and 33 for NPTL; real-time queued signals
>> available to the application ranges from SIGRTMIN (34) to SIGRTMAX(64).
>
> Yes... exactly.
>
>>> On LinuxThreads, the second real-time signal is used,
>>> if real-time signals are available, otherwise
>>> .B SIGUSR2
>>> is used.
>>
>> IIRC, this was true on 'older LinuxThreads'. Never used real-time
>> queued signals as well ? (To verify...)
>
> I'm not quite sure what you want to say there. Can you say some
> more please.
Sorry, typo and missing words make this sentence hard to understand...
Second try:
Newer version of LinuxThreads uses RT signal as well? (this claim has to
be verified).
>
>>> .SH EXAMPLE
> [...]
>
>> sleep(3) is a CP on Linux (AFAIR, sleep is a "may be CP").
>
> Not sure what you are wanting to saying here; should something
> be changed in the page? (BTW: sleep() *is* a CP in POSIX.1.)
>
> [...]
I hadn't the list at hand, and I thought mistakenly that sleep() is not
a mandatory CP. Thanks for the note.
Cheers,
Loïc.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-11-22 6:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-14 17:17 For review: pthread_cancel.3 Michael Kerrisk
[not found] ` <cfd18e0f0811140917q5340504akc53d7ffa3eea483-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-14 18:01 ` Bert Wesarg
[not found] ` <36ca99e90811141001s4b8eb58fnee18ff3b14f4977e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-14 18:37 ` Michael Kerrisk
2008-11-17 19:41 ` Loic Domaigne
[not found] ` <4921C900.6040302-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org>
2008-11-18 13:55 ` Michael Kerrisk
[not found] ` <4922C93D.1010804-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-11-22 6:52 ` Loic Domaigne [this message]
[not found] ` <4927AC30.6030107-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org>
2008-11-24 17:30 ` Michael Kerrisk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4927AC30.6030107@domaigne.com \
--to=tech-z4jmkddsf89wk0htik3j/w@public.gmane.org \
--cc=K.Weiss-Pt+Xe7GJXK+P2YhJcF5u+nqWYbMAw+HU@public.gmane.org \
--cc=bert.wesarg-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org \
--cc=josv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.