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

[Alexandre Oliva <aoliva at redhat dot com>]

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.

>> @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 ;-)

>> @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.

> 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.

> 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.


Thanks for the review and the insights!

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer