On a dual processor NT machine (NT v4) you can run 2 copies of POVRay at the
same time with minimal interference.  To minimize CPU thrashing I'd suggest
you use the set affinity command via the task manager processes tab.

--
Jim

Check out my web site  http://www.kressworks.com/

Ron Parker <ron### [at] povrayorg> wrote in message
news:slr### [at] parkerrfwicom...
> 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