On Jul 1, 2008, at 6:51 AM, Charles Oliver N. wrote:
The Java deprecations were done because it’s provably impossible to
share in-process resources and safely terminate threads at will.
i think java is correct to have done so, precisely because people have
found it too hard to write safe code using those mechanisms but as you
point out, you can do the same with processes while no OS has limited
us yet. why? i think it’s because sharing data between threads, or
processes, is both dangerous and powerful. when someone builds an OS
that supports message passing we’ll see those operations limited on a
processes too i bet but, for now, they are just too useful despite the
danger and do work ‘much’ of the time which, for better or worse,
seems to be the MO for many programming tasks.
Probably not, but hopefully neither will typical IPC mechanisms,
which are almost as painful to get right and make reliable.
in fairness we’re talking about ruby here where that is definitely not
true. it’s extremely painless to have reliable ipc with ruby using
drb or com with sqlite as a message store.
. But it’s absurd to say that processes can do everything threads
can, otherwise we’d have a massive process bloat for almost every
nontrivial applications we use.
for the record i’m not saying that - i’m saying that processes are a
better starting point for most people wanting to gain parallelism in
ruby for most problems. threads are appropriate at times too but, in
ruby, the disadvantages like lack of cpu migration, blocking the
entire process (in win), etc limit their usefulness - jruby excepted
of course (no jab, it’s a huge advantage jruby has over the mri)
a @ http://codeforpeople.com/