This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding reentrancy information to safety notes?

Hi Carlos,

You better turn on the spell checker in your mailer (or update
its dictionary) ;-). ("Ree_n_tran*")

On 12/30/2014 04:45 PM, Carlos O'Donell wrote:
> Michael, Peng, Alex,
> We have had some recent discussions about reetrancy safety
> of dlopen. My goal is going to be to ensure that dlopen
> and in general the intefaces in libdl remain reetrant to
> allow user implemented malloc to use these interfaces to
> load libraries that themselves may have reetrant helper
> functions.
> This raises the question: How do we clearly document which
> functions are reetrant?
> My thoughts are as follows:
> * Add some introductory text about reetrancy in the safety
>   section. This text will discuss that AS-safe functions
>   are reetrant because they must be to be AS-safe. Note that
>   reetrant functions need not be AS-safe nor MT-safe.

Sounds good to me.

> * Add a "R-Safe" and "R-Unsafe" to indicate safety with respect
>   to reetrancy.

Sounds odd to me. Why not just say "Reentrant" and "Nonreentrant",
rather than add new terms?

> * Immediately annotate all AS-safe functions as R-Safe.

Okay -- modulo preceding point

> * Review all of the "_r" functions for reetrance safety.

> Thoughts?
> My review of other Unices indicates this is probably the
> last type of safety that documented by other systems.

I am not quite clear what you mean by "last...documented".
Do you mean: few other systems document it?



Michael Kerrisk
Linux man-pages maintainer;
Linux/UNIX System Programming Training:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]