Reentrancy and Reentrant in C?

Question

I am reading a book called Linux System Programming. Quoting from this book:

What about system calls and other library functions? What if your process is in the middle of writing to a file or allocating memory, and a signal handler writes to the same file or also invokes malloc()? Some functions are clearly not reentrant. If a program is in the middle of executing a nonreentrant function and a signal occurs and the signal handler then invokes that same nonreentrant function, chaos can ensue.

But then it will follow:

Guaranteed-Reentrant Functions

Functions guaranteed to be safely reentrant for use in signals

some functions here..

write()

some functions here..

I am confused, is write() reentrant, or not? Because I think it clashes with the statement:

What if your process is in the middle of writing to a file?

Ancillary

Answer 1

Just to add what Mr. @Joachim Pileborg already mentioned in his answer, as per the wiki entry for Reentrancy, the basic rules for a function being re-entrant are

1. Reentrant code may not hold any static (or global) non-constant data.
2. Reentrant code may not modify its own code.
3. Reentrant code may not call non-reentrant computer programs or routines.

To elaborate, the function, if reentrant, will not have any issue with its own implementation (inducing the internal data structures it uses for itself) whether being called from different context.

A parameter, (such as a file descriptor) which is supplied to the function does not affect it's reentrancy.

So, for write(), the function itself is Reentrant, but if called with same file descriptor from different thread, it will obviously produce erroneous result. Again, that does not mean, the Reentrancy of write() is gone. It is Reentrant, but not thread-safe, and these two are different aspects.

Illyes

write is thread-safe in current Linux kernel. See my answer for details. – Taka

Answer 2

Reentrancy have more to do if you could call a function from different contexts without disturbing another call from another context.

Take for example the strtok function. It typically contains a static local variable to keep track of the next position in the string you're tokenizing. Since local static variables are shared between all calls to the function, calling the function from two different contexts will cause problems.

The write system call, on the other hand, have no such internal data that it stores between calls, which makes it safe to call from different contexts.

---

It's important to note that reentrant isn't the same as thread-safe. Take the write function for example, because it's reentrant you can call it from different threads using different files without worrying that internal data would be clobbered. However, it's not thread-safe. Calling it from different threads using the same file-descriptor will lead to problems.

Bonnee

But does re-entrant also mean thread-safe? I think not! (I think is important a note about that) – Yoon

Please explain what you mean with the term context. – Iphigenia

@SergioFormiggini Correct, I'll add a note about it. – Bonnee

Sir, I've just added an elaboration of your points as an answer, as I thought it will be too much to put in a comment. Can you please review once? – Illyes

Answer 3

The documentation you're quoting refers to signal handlers. That is a very specific type of function which are called on exceptional cases and are to be considered specific systems programming. They defy normal control flow in the program.

If you are not writing signal handlers this documentation is not really of use for you. Nevertheless, here's the list of function that are signal safe on Mac OS:

$ man sigaction

The following functions are either reentrant or not interruptible by
signals and are async-signal safe.  Therefore applications may invoke
them, without restriction, from signal-catching functions:

Base Interfaces:

_exit(), access(), alarm(), cfgetispeed(), cfgetospeed(),
cfsetispeed(), cfsetospeed(), chdir(), chmod(), chown(), close(),
creat(), dup(), dup2(), execle(), execve(), fcntl(), fork(),
fpathconf(), fstat(), fsync(), getegid(), geteuid(), getgid(),
getgroups(), getpgrp(), getpid(), getppid(), getuid(), kill(),
link(), lseek(), mkdir(), mkfifo(), open(), pathconf(), pause(),
pipe(), raise(), read(), rename(), rmdir(), setgid(), setpgid(),
setsid(), setuid(), sigaction(), sigaddset(), sigdelset(),
sigemptyset(), sigfillset(), sigismember(), signal(), sigpending(),
sigprocmask(), sigsuspend(), sleep(), stat(), sysconf(), tcdrain(),
tcflow(), tcflush(), tcgetattr(), tcgetpgrp(), tcsendbreak(),
tcsetattr(), tcsetpgrp(), time(), times(), umask(), uname(),
unlink(), utime(), wait(), waitpid(), write().

Iphigenia

Answer 4

The answers from Sourav Ghosh and Joachim Pileborg seem not to be correct regarding thread-safety of write:

write shall be thread-safe pursuant to POSIX.1-2008 as it is not in this list.

However, from glibc wiki:

At present the Linux write syscall is not MT-safe. Multiple threads racing to the write may get the same file position value and write to the same position resulting in the loss of data.

Seems this issue was fixed in the Linux kernel (see linux kernel mailing list).

Taka