When tasks replace objects

by ranit8 • 14 years ago

10 1 14 years ago

bascule• 14 years ago

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

When tasks replace objects

Related Stories