Re: Thread-, Signal- and Cancellation-safety documentation

[KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>]

(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. :)