[INN-COMMITTERS] inn (frontends/rnews.c innd/util.c nnrpd/p

Russ Allbery rra at stanford.edu
Mon Mar 11 22:26:14 UTC 2002


Forrest J Cavalier <mibsoft at epix.net> writes:

> When you know why vfork is not used correctly, those are often the
> pieces that need to change to use pthreads.

Makes sense.

> (The changed line counts look small, I didn't look at the changes.)  But
> if you could remember to insert comments about why something is not
> thread-safe or vfork safe, it will help when INN goes to threads (which
> will be a couple of versions from now, I know.)

There were only three places left that used vfork.  One was the code that
ran the authenticators in nnrpd, one was the code that ran external
programs in rnews to handle UUCP batches, and one was the process spawning
code in innd.  In all cases except maybe the rnews case (which is the
least performance critical), the child code was *at least* potentially
calling syslog before calling exec.  In nnrpd it was assigning to
variables, calling random other functions, and doing all sorts of stuff.

The rules for vfork (and I'm sure you already know this, Forrest, but this
is just for folks who may not already) are basically that if you use
vfork, the *only* things the child process should do is to call exec*() or
_exit().  I think *maybe* close() is allowed, but when you start doing
stuff like dup(), I start getting worried, and doing anything that fiddles
with global buffered state inside libc, like calling syslog(), is right
out.  A real vfork implementation cheats by not actually allocating new
process space or setting copy on write on any of the pages for the child
process, so *anything* it does is also writing into the parent's process
space.

I think we're safer when it comes to thread-safe code, because with
thread-safe code you're allowed to call any thread-safe function of libc
(which is a much broader set of functions than the ones that are
vfork-safe) and you're allowed to arbitrarily modify local variables.  I
think that some of those places would have actually been thread-safe.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list