CODEWITHSUNDEEP
posixreentrancy
eonil
eonil

Reputation: 86165

How to determine whether a POSIX function is re-entrant or not?

While writing directory iterator, I discovered that readdir function is not re-entrant. readdir_r function seems re-entrant version of that, but I don't know how to confirm this. Though readdir is explicitly marked non-reentrant, but there's no mention for readdir_r.

Is there a way to check re-entrancy of specific POSIX function? How to check re-entrancy of a POSIX function?

Upvotes: 1

Views: 693

Answers (1)

eonil
eonil

Reputation: 86165

Here is a POSIX.1c policy for re-entrancy.

Here's my summary.

  • All functions are re-entrant by default.
  • Some functions cannot be re-entrant due to various reasons. They will have separated re-entrant version. They are also explicitly marked.
  • Some functions implies huge performance penalty for reentrancy. They will have separated non-reentrant version for single-threaded performance by sacrificing safety. They are also explicitly marked.

Here's another caveat claim.

Cited from the text.

Header Files you Need for Thread Programming

#define _REENTRANT
#include <pthread.h>
#include <sched.h>

_REENTRANT indicates that the reentrant (i.e. thread safe) versions of the standard libraries should be used.

The header file pthread.h defines the POSIX thread API.

The header file sched.h defines the process and thread scheduling API. Of the functions explained here, only sched_yield() requires it.

Anyway, there's another claim of these steps are not required anymore: Is it required for me to add a _REENTRANT macro during compile time to make my errno thread safe? It seems we don't need to define _REENTRANT anymore.

The term reentrancy is a legacy term from single threaded environment. Anyway, POSIX.1c presumes multi-threaded environment, and it silently assumes re-entering from other thread cases.

Upvotes: 1

Related Questions