Re: Thread-private mappings and graphics (was Re: Per-Processor Data

Linus Torvalds (torvalds@transmeta.com)
13 Dec 1999 22:28:28 -0800


In article <Pine.LNX.4.20.9912132229460.10986-100000@imperial.edgeglobal.com>,
James Simmons <jsimmons@edgeglobal.com> wrote:
>>
>> The fact is that many workstation apps using the OpenGL API rely on
>> threadsafe GL support, and slow lookups would cripple their performance.
>> We need to explore implementation options more, but the issue certainly
>> could be addressed by thread-private mappings, as is done today on IRIX
>> and other platforms.

It will never happen on Linux.

I'm suprised an SGI person hasn't learnt from past mistakes. IRIX is
unstable, and unmaintainable, and please just face it - it's because SGI
had the "cool feature of the day" disease.

Thread-private mappings WILL NOT HAPPEN. You can obviously do them in
SGI Linux, but that way lies madness, and it's something I'll keep
pointing out in public.

You can have thread-private _pointers_. Just have different mappings of
the same hardware context if you have to, and just have different
pointers to it in different threads.

>He is totally right.The DRE (Direct rendering engine) in
>drivers/sgi/char/graphics.c is severly broken.

However, thread-private mappings are FUNDAMENTALLY broken. They
completely break the whole point of having a thread in the first place,
and I can only suggest that if you want them you should look at this
great concept that was invented, oh, thirty years ago by people more
intelligent than you or I.

Namely "fork()". Which gives you the tread-private mapping you want.

If you want threads with shared address spaces, then make them SHARED.
None of this private stuff. It's not on the table, and it won't be.
I've explained to people why before, and I bet I'll end up explaining
again, but the short and sweet of it is that you CANNOT do
thread-private mappings without losing most of the performance advatages
of a thread in the first place.

And once you lose the performance-advantage of threads, not all that
much else remains. Threads certainly aren't any easier to program than
processes...

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/