gwyn@smoke.BRL.MIL (Doug Gwyn) (06/01/89)
In article <8591@chinet.chi.il.us> les@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.