On Friday, May 10, 2002, at 09:20 , Chas Owens wrote:
[..]
> In many operating systems fork is implemented using copy-on-write. This
> means that when you fork both processes refer to the same memory
> locations until one of them tries to change the bytes stored there. At
> that time the change bytes are copied to a new memory space for the
> child.
[..]
I saw this and it reminded me that you had proposed threads
as a 'shared memory' solution - but you can get into as much
of a problem in the thread space just as quickly without managing
who does the synchronization on any globally accessible memory...
We got to the point where we started to just say,
"Oh don't worry about that, they are
planning to just fork another thread..."
at one gig - as the 'designers' and 'management' displayed
a complete lack of awareness about the consequences of their
blithe optimism that 'threads are the wave'....
Let's just say they nailed a sun E10000 to the bulk head
as they bloated their one Process........
So folks may wish to understand the problems of 'process
management', shared memory, and the various types and
forms of Interprocess communications, before they try to
avoid the problems of process management, shared memory,
and Interprocess communications, by
'well we can do it in threads -
they are lightweight .....'
and learn that a camel can only carry so much hay....
and it ain't any better with fresh brewed java or
WayCoolHotNewBuzzGeneratedTechNoirWaveOfTheFuture
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
