Threads vs Processes

[Joe Knapka]

John Henry wrote:

> 
>>Carl,
>> OS writers provide much more tools for debugging, tracing, changing
>>the priority of, sand-boxing processes than threads (in general) It
>>*should* be easier to get a process based solution up and running
>>andhave it be more robust, when compared to a threaded solution.
>>
>>- Paddy (who shies away from threads in C and C++ too ;-)
> 
> 
> That mythical "process" is more robust then "thread" application
> paradigm again.
> 
> No wonder there are so many boring software applications around.
> 
> Granted.  Threaded program forces you to think and design your
> application much more carefully (to avoid race conditions, dead-locks,
> ...) but there is nothing inherently *non-robust* about threaded
> applications.

In this particular case, the OP (in a different thread)
mentioned that his application will be extended by
random individuals who can't necessarily be trusted
to design their extensions correctly.  In that case,
segregating the untrusted code, at least, into
separate processes seems prudent.

The OP also mentioned that:

>  If I have a system that has a large area of shared memory,
 > which would be better?

IMO, if you're going to be sharing data structures with
code that can't be trusted to clean up after itself,
you're doomed. There's just no way to make that
scenario work reliably. The best you can do is insulate
that data behind an API (rather than giving untrusted
code direct access to the data -- IOW, don't use threads,
because if you do, they can go around your API and screw
things up), and ensure that each API call leaves the
data structures in a consistent state.

-- JK