Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page) | Date | 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/
| |