No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 Spaceships

Re:No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 ... by IgorPartola on Wednesday October 16, 2013 @04:59PM (#6562133)

Necessary in all cases or necessary in some cases? My take on this is that you can successfully pass state around if it's small enough and only one actor cares about it at a time. Once it gets big enough you probably want to use an external service to store and synchronize it (a database), and then it matters less how your program is structured.

I suppose the exception to this might be gaming and simulations where what's more important is speed as opposed to durability of your data, yet you have lots of state to keep track of.

[ Parent | on HN ]

Re:No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 ... by pron on Wednesday October 16, 2013 @08:14PM (#6562895)

If it were that simple, people wouldn't be spending so much time configuring caches or using Redis. I think most non-trivial applications require some central, shared, data store. More often then not, this data store becomes a bottleneck that limits scaling. Databases compete with one another over which interferes with scaling the least.

If you accept the premise in the opening quote about Amdahl’s law, then you must consider that any global or semi-global lock has a huge impact on scalability. Sometimes we have no choice, but I believe that we can and should remove many single-points-of-synchronizations while still keeping the programming model relatively simple. I also believe that rather than hindering scalability, a database can help achieve it.

[ Parent | on HN ]

Re:No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 ... by IgorPartola on Thursday October 17, 2013 @10:13AM (#6565444)

That is definitely true. Databases are necessary. In fact in-memory data stores that can handle large volumes of data are not all that useful since they usually lack things like backups, etc. Not everyone is writing a RabbitMQ-like system. And of course locking plays a central role in all of this.

What I am saying is that when you accept that synchronization is going to be handled by your database of choice, it becomes somewhat less important how you actually structure your application in terms of performance. There are reasons not to use callbacks, but if you go with threads, actors, processes, etc. is now a choice between how you want to utilize memory and to an extent which technology your runtime supports best.

[ Parent | on HN ]