On 5/27/06, ReggW <me / yourhome.com> wrote:
> Francis Cianfrocca wrote:
> > You're making a very interesting point, one I've made many times: you're
> > saying to write cooperative multiprocess rather than multithreaded
> > programs.
>
> This may work well on Linux, but multiprocesses are very heavy on
> Windows versus multithreads.
>
> > If you take aggregate costs into account (including time-to-market and
> > lifecycle maintenance and support), this approach can be far better than
> > multithreaded because it's so much more robust and easier to do. Whether
> > it's as fast, however, is a highly hardware and OS-dependent question.
>
> But with multiprocess you would need to now develope a shared memory
> scheme (MapFiles on Windows) or something similiar if your processes
> need to communicate with each other.
> I would just prefer to have native threads and the
> syncronization/locks/etc available to me to do what I need to do.
>

This is an excellent thread, full of good thoughts.
I'll chime in and say that my opinion lines in this direction:
http://rubyurl.com/DJB
I'm not sure a 'coordination language' is the right direction, but I
do think that threads are a deeply flawed model.
An earlier issue of Computer made some strong arguments in favor of
transactions, as well.