Re: help with huge memory consumption??

On Mar 6, 6:49 am, phil-news-nos...@xxxxxxxx wrote:

Programmers should choose to use threads _only_ when they fully
understand _why_ their application benefits from threads at a
level greater than the
risks that threads pose to their application, whatever size it might be.
They should also consider process separation where possible
(and I believe
it is more possible than commonly done today). Making processes talk to
each other, of course, does involve more work, and using less efficient
methods that can have an impact when there is a higher volume of data to
go between tasks and work units (e.g. an IM or IRC server).

I agree with you completely. The problem is that for a huge category
of real-world problems, threads are currently the only alternative to
'process per client/task'.

I would love to see more work done developing process-pool
technologies that would allow programs to use pools of processes as
easily as they use pools of threads. Ways to manage a pool of file
descriptors across processes and easily manage dynamic objects living
in shared memory would go a long way towards this end. (Ideally with a
robustness protocol to 'pick up' and 'put down' an object in shared
memory such that a corrupt process can't scribble on objects it didn't
choose to 'pick up'.)

In a 64-bit address space, globally-unique address space is not a
scarce resource. So allocating objects and pointers in shared memory
without the need to rebase pointers could become a reality.

One of the issues that I complain about a lot that you are kind of
touching on is the irrational worship of performance. It costs some
time to create a process, and threads don't have that time, so threads
must be better. Often performance is not so important that it's not
worth trading it off for other things that are important. These
include ease of design, reliability, modularity/reusability,
maintainability, and so on.

DS

.