Hacker News new | past | comments | ask | show | jobs | submit login

Great follow up to the original argument. I certainly hope some language designers start to look really hard at these arguments.

    Off the top of my head:

    * Cancel all threads in the bundle.
    * Block until all threads in the bundle exit.
    * Block until at least one thread in the bundle exits. Cancel all the other threads.
I think there also is one 'restart any exiting thread' and a variant of the block until all rule where only failed threads are restarted. Hmm, actually - perhaps there should be variants specifying the behavior of failed threads in all cases?



> perhaps there should be variants specifying the behavior

It feels like Erlang/OTP is being reinvented right here again.

Once you get deep enough into concurrency the ideas start to converge on killable isolated processes with asynchronous message passing and programmable behaviors. Because with shared memory killing a thread has unpredictable consequences, you need to either enforce isolation or avoid consequences in some other way, like by not having multithreading and using an event loop. Isolated processes need to communicate with other processes somehow. You need message passing. But it has to be asynchronous to make it possible to implement various waiting behaviors. With event loops you get there via cancellable contexts and higher order programming, but on a single cpu. Getting into multi core or distributed systems yet again requires asynchronous message passing. At the end it's all actors everywhere.


> It feels like Erlang/OTP is being reinvented right here again.

I thought the same thing. There are some cases like low message passing computational tasks where you can get away with simple async futures + fetch_future (being a computationally oriented language Julia encourages this model) but in the end actors are pretty great at generalizing concurrency.


What would be some usecases for which synchronous is insufficient and one has to reach for the hard to reason about asynchronous?


Synchronous messaging is insufficient for making multiple requests at once and waiting for the responses. Also asynchronous messaging allows for optimistic notifications -- for example to clear a cache when coherency isn't required.

With asynchronous messaging it's simple to build synchronous interactions if desired --- send a message and wait for a response; but you can't build asynchronous interactions on top of synchronous messages.


Let's say you are writing a parallel crypto hasher... Which if you're part of a pool is the case at the nacro level, the first to get to the answer should probably cancel the rest (though strictly speaking it's not necessary)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: