On Thu, 02 Mar 2000 00:40:47 +0200, Peter Popov wrote:
>Gee, these keyboards are getting crappier every day. Ron's caps lock
>key got stuck, and the darn thing isn't even three months old. 

Actually, that keyboard is more like two years old.  But believe it
or not, I didn't use caps lock to type that line. 

>I believe the problem lies in basically having to redesign everything
>from scratch, which the Team would not be likely to do solely for the
>sake of multi-threadedness.

Pretty much.  Mainly, the problem lies in the overuse of global variables.
Since that's such a bad idea anyway, we're working on getting them under
control for "a future release" but it still might not be easy to do 
multiple threads, due to the fact that there is no standardized way to
do multiple threads across all supported operating systems.

>Memory consumption? I believe two threads can share the same memory
>(for reading at least) but not so for two processes.

Two threads in the same process share all the same memory; this is
the main problem: they can trample on each other's global variables.
Having variables local to a specific thread is actually somewhat
complicated, at least in Windows.

Two processes should be able to share an executable image, but I 
wouldn't be the least bit surprised to hear that this isn't implemented
on Windows-based operating systems, or at least those before W2K.  I 
know I was surprised to find out there's essentially no memory 
protection on executable code (though I went through the motions and
VirtualProtect'd the pages I needed to modify anyway, just for the
sake of safety.  They may one day actually make that code do something.)

Two processes can opt to share a read/write region of memory, at least
in Windows, by using memory-mapped files, but this is fraught with 
danger in that some versions of Windows will map them to the same 
address in different processes (9x, Millennium) and some will map 
them to completely different addresses (NT 4 and 2000).  This is a 
problem if you elect to store any pointers in the shared memory, as
they'd only be valid in one process.  The workaround is relatively 
simple, but it's still a pain to have to think about such things.
Worse, if you do your development on 9x, you'd never know the problem
existed.  Even Microsoft has fallen prey to this caveat in one of 
their more specialized development tools.  (Though to be fair, the
tool was for working with a feature that didn't exist on NT in a 
publicly released version at the time.  Unfortunately, I was using 
an unreleased (i.e. not even beta) version, and I needed the tools.)

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message