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?
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
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.
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.
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().