is popen really thread safe? - multithreading

Question

Recently, I am running into trouble of calling popen, it seems to be not thread safe.
The following is the code snippet from the source code link: http://androidxref.com/9.0.0_r3/xref/bionic/libc/upstream-netbsd/lib/libc/gen/popen.c
static struct pid {
struct pid *next;
FILE *fp;
int fd;
pid_t pid;
} *pidlist;
static rwlock_t pidlist_lock = RWLOCK_INITIALIZER;
FILE *
popen(const char *command, const char *type)
{
struct pid *cur, *old;
...
pipe2(pdes, flags) // A
...
(void)rwlock_rdlock(&pidlist_lock); // C
...
switch (pid = vfork()) { // C.1
case 0: /* Child. */
...
_exit(127);
/* NOTREACHED */
}
/* Parent; */
...
/* Link into list of file descriptors. */
cur->fp = iop;
cur->pid = pid;
cur->next = pidlist; // D
pidlist = cur; // E
(void)rwlock_unlock(&pidlist_lock); // F
...
}
Observing the above code, it acquired a read-lock at C, but, inside the scope, it did some write operations at E. So, there will be possibly multiple read threads who are writing to the variable "pidlist" in the same time.
Does anyone know whether it is a true issue or not?

Answer 1

Looking at the code, it is not how you outline it.
Here is a paste from the given link http://androidxref.com/9.0.0_r3/xref/bionic/libc/upstream-netbsd/lib/libc/gen/popen.c
80FILE *
81popen(const char *command, const char *type)
82{
83 struct pid *cur, *old;
94 if (strchr(xtype, '+')) {
...
100 } else {
103 if (pipe2(pdes, flags) == -1)
104 return NULL;
105 }
106
...
113
114 (void)rwlock_rdlock(&pidlist_lock);
115 (void)__readlockenv();
116 switch (pid = vfork()) {
117 case -1: /* Error. */
...
127 case 0: /* Child. */
...
154 execl(_PATH_BSHELL, "sh", "-c", command, NULL);
155 _exit(127);
156 /* NOTREACHED */
157 }
158 (void)__unlockenv();
159
160 /* Parent; assume fdopen can't fail. */
161 if (*xtype == 'r') {
...
167 } else {
...
173 }
...
179 pidlist = cur;
180 (void)rwlock_unlock(&pidlist_lock);
181
182 return (iop);
183}
It is
do the file stuff (pipe2() or socketpair())
acquire the lock (this will avoid the child doing silly things)
vfork()
on the child, reorganize filedes and execl
on parent do some filedes stuff unlock and return
I do not see what would be the problem.