This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha at sourceware dot org
- Date: Sun, 07 Apr 2013 23:37:38 -0400
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home> <51536E3F dot 90105 at gmail dot com> <ory5cy9k7p dot fsf at livre dot home>
(4/4/13 3:20 PM), Alexandre Oliva wrote:
> On Mar 27, 2013, KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
>
>> Solaris have three MT-safe leve, MT-safe, MT-unsafe, and MT-safe with exceptions.
>
> We may end up taking this path if we decide we're not pursuing full
> safety in some cases, indeed. After all, documenting the cases in which
> it's safe or unsafe is probably better than refraining entirely from
> using a function because in some corner case it might be unsafe.
Hm. OK. Then, I believe we need to describe the meanings of "MT-safe" and "MT-unsafe".
>
>>> @deftypefun int printf (const char *@var{template}, @dots{})
>>> +@safety{@mtunsafe{glocale-revisit}@asunsafe{badstream, glocale-revisit}@acunsafe{memleak, lockleak, badstream}}
>
>> I believe printf should be MT-safe w/ exceptions or special.
>> It has wild industrial consensus that it is thread safe and more over no better alternative.
>> So, I believe we shouldn't completely discourage to use printf. and nit, printf should refer
>> register_printf_function. it also break thread safety.
>
> Yeah, I noticed that, too, along with other potential problems: I've
> spend about a month since I posted the first patchset last week ;-)
> reviewing printf and (so far) a few of its dependencies. Besides malloc
> (that I'd tentatively assumed as MT-safe before even looking at it or
> thinking it worth documenting, a decision I ought to revisit in the
> light of your comments), there are dependencies on gconv, which brings
> in the dynamic loader, and the kitchen sink ;-)
Yeah. Indeed.
>>> @deftypefun int sprintf (char *@var{s}, const char *@var{template}, @dots{})
>>> +@safety{@mtunsafe{glocale-revisit}@asunsafe{glocale-revisit}@acsafe{memleak}}
>
>> Solaris mark sprintf and snprintf mark as AS-safe (w/ exceptions).
>
> vfprintf, called by all of the *printf functions, internally calls
> malloc in some circumstances; can they really be AS-safe? I guess I'll
> see once I get to review malloc with these concerns in mind.
No. there are several exceptions. Then I said "AS safe w/ exceptions".
Now, vfprintf uses malloc following case.
- uses %ls or %S and string is larger than alloca threshold.
- uses the field width specifier and/or the precision specifier and
their width is larger than alloca threashold.
- number of arguments are really much (> alloca threshold).
They are mere corner case and no applications hit this issue even though
a lot of applications now use sprintf() in signal handler. so let's document
to itemize corner cases.
And, I'm ok to define vfprintf as AS-unsafe if you decide not to use "w/ exception".
My point was, sprintf is safe in signal handler under the industrial standard. and
I don't think applications will start to rewrite if glibc says "hey! it's unsafe".
>> This is another interesting part to me. feof_unlocked is thread safe under
>> many OSs. However, as far as I know, all OSs mark it as MS-unsafe because
>> manual describe the interface promising, not current implementations.
>
> That's an aspect that hadn't even crossed my mind. I was asked to
> document current behavior; I guess we can always adjust the
> documentation so as to weaken our commitments in spite of current
> behavior.
So then, please parse my email as "kosaki didn't understand Alexadre's intention".
>> 2. _IO_link_in touch global io list and it's not recursive call safe.
>
> Thanks for this observation; I think you're right that I made a mistake
> and missed this point.
> @deftypefun int fclose (FILE *@var{stream})
>+@safety{@mtsafe{}@assafe{}@acunsafe{lockleak, memleak, fdleak}}
one more thing. I also don't think fclose is as-safe. because _IO_un_link()
is also touch _IO_list_all and it is not recursive safe.
In other words, _IO_list_all touch is as-unsafe in general.
> Thanks for the review and the insights!
Thank you too. :)