List of APIs not required to be thread-safe

The standard C library, glibc, has many older functions that, in the words of the Open Group manual, need not be thread-safe (or are not required to be thread-safe). All functions defined by this volume of POSIX.1-2017 shall be thread-safe, except that the following functions need not be thread-safe. What does that actually mean? Simple: these APIs are not thread-safe. So, be careful—do not use them in MT applications. The complete list can be found at: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01.

Of course, the preceding list is only valid as of POSIX.1-2017 and is bound to get outdated. The reader must be aware of this recurring issue, and the need to constantly update information like this.

Also, they are mostly library-layer (glibc) APIs. Of all the preceding APIs, only one of them—readdir(2)-is a system call; that too is considered deprecated (we are to use its glibc wrapper, readdir(3)). As a rule of thumb, all system calls are written to be thread-safe.

An interesting aside: PHP, a popular web-scripting language, is not considered thread-safe; hence, web servers that serve PHP pages do so using the traditional multiprocess model and not a faster multithreaded framework (for example, Apache uses its internal mpm_prefork module—which is single-threaded – to deal with PHP pages).

So, seeing what we have just discussed, does one conclude that glibc is no longer viable to develop thread-safe MT apps? No sir, work has been done to convert (refactor, really) many of the preceding APIs to render them thread-safe. Read on.

Table of Contents for List of APIs not required to be thread-safe

Create new playlist

Sign In

Sign Up

Table of Contents for
List of APIs not required to be thread-safe