

When tasks replace objects - ranit8
http://drdobbs.com/parallel/232700402

======
bascule
There's so much wrong with this article I don't even know where to begin. I
guess I'll start with:

"In most implementations, the data sent to actors must be immutable."

This is true of Erlang. It's not true of many other actor systems, including
Akka, which merely suggests arguments be treated as immutable.

Perhaps the most interesting system that doesn't depend on immutability is
Kilim. Kilim allows ownership transfer of objects between actors, causing
exceptions to be raised if you attempt to access objects which have been sent
to other actors. No copying required!

After dismissing actors, the article goes on to talk about all the pitfalls of
concurrency which have been areas of intense research for at least the past 40
years, and concludes it's all a big mystery and we don't know how it's all
going to work out yet. WAT?

Perhaps even more WAT was this letter at the end:

"All the applications use I/O completion ports for task queuing. The general
flow is that a task arrives in the I/O completion port queue and is picked up
by the next available thread, based on information contained in the Completion
Key and Overlapped data structure, and is routed to the appropriate task
handler."

I/O completion ports? Really? I'm not a Windows guy, but last I checked that
required a system call.

How about using lock-free ring buffers to dispatch tasks to cores instead?

<http://code.google.com/p/disruptor/>
<http://www.infoq.com/presentations/LMAX>

\--

All that said, what will the concurrent alternative to objects be? How about
concurrent objects:

<http://celluloid.io>

