threads (was: What kinds of things would you want in the GNU OS?)

[Doug Gwyn]

In article <8591 at chinet.chi.il.us> les at chinet.chi.il.us (Leslie Mikesell) writes:
>Wouldn't there be a problem with static data in library routines
>(or anywhere else)?

There sure would be.  This issue came up several times while debating
what the specifications should be for some of the standard library
functions.  Unfortunately, existing practice in some cases is unsuitable
when parallel threads of computation are used.

We recently tracked down a mysterious bug in some of the daemons on a
Gould UTX-32 system; the daemons were using syslog() which in turn used
vfork(), BSD's thread-creation mechanism, then invoked sigvec() for the
first time; UTX-32 establishes a signal catcher stack etc. the first
time that sigvec() is invoked, and it uses a static "first time" flag
to determine whether this needs to be done.  The result was that the
child branch of the vfork() worked fine, but after it terminated the
parent branch no longer actually had a valid signal catcher even though
the library code thought it did (due to the shared flag having been
updated).

One of the reasons the biggest names in computer science have spent so
much time on the theory of concurrent processes is that it's a really
hard problem.