🚀 go-pugleaf

In article <1993May3.171615.25882@spectrum.xerox.com> leisner@eso.mc.xerox.com writes:
>In the '92 Summer Usenix paper "Implementing Lightweight Threads"
>by D. Stein and D. Shah and SunSoft, they talked about a 
>pragma in the C compiler to communication thread private
>data...

>This is necessary if each thread gets its own copy of errno...
The SGI solution to this (I use their thread implementation in some
semi-parallel image processing stuff) is to have a function that returns
errno (from a private data area).  This area may be a non-shared page
or it may be shared with a unique pointer; I don't remember.  In any
case, this solution requires a library which is different from
the normal library whenever you use threads; this is needed anyhow since 
you have to serialize the use of the _iob structures and the malloc arena.
They then provide a function to access (and another to set) errno.
This communications block may not be shared; I may have read things wrong;
it acts as if it isn't.

>How (or does) gcc plan on getting around the problem?
gcc isn't really part of the problem; it can be solved in the library
and/or the page manager (with the cooperation of the linker).
Remember that errno is a library construct, and any program using
threads MUST be aware that it is using threads.  There are MANY
problems that come from sharing an address space that aren't addressed
here (you may have to serialize access to any address depending on the
program semantics; unix/C requires you to be aware of this.  Yes,
there are parallel systems with this built-in; many of them program
in C and use function calls or split pages with a special library
manager to implement arbitration.

C is NOT a parallel language; making it that will require much more
than a pragma.  The implementors of C were using the KISS principle,
forcing all OS-(and other context)-dependent constructs into functions
from the library.  I realize that ANSI has muddied this, but it still
remains that C itself contains nothing to either aid or hinder thread
programming; all of that rests in the library.

BTW - it's real easy to shoot yourself in the foot using threads; if
you think C is bad that way by itself, try threads...  Even Ada, where
the tasking/rendezvous is built into the language (now admitted to be
a mistake by some of the early implementors), lets you shoot yourself
in the foot very easily using shared data.

-- Pete