Hacker News Reader

Comment by lomnakkus | Hacker News Reader

> You're going to have to deal with this at a higher level than the line of code which tried to save the file.

Exactly, but that's the point I'm trying to make, perhaps badly. My point is: Can a function call fail in Erlang, i.e. can it just "not return"? AFAIUI as long as you're inside a message handler, this cannot happen -- any function call will receive a return value. In other words: Function calls inside message handlers are synchronous.

In the Actor model conceived by Hewitt, this is not the case. Now, this would be a huge problem for any foundational theory, but he seems to get around it by just assuming infinte resources (queues), so it all works out in theory.

View on HN

> My point is: Can a function call fail in Erlang, i.e. can it just "not return"?

Kinda? Function calls in Erlang are intra-process and synchronous, but the function could send and receive messages internally and never return because it never got a response and did not have a timeout setup.

When you're talking about actual messages between processes though, they are asynchronous and they can get lost (if only because the process you're sending a message to is on an other physical machine).

I think there are two separate issues here: unbounded queues vs finite resources and also the overhead of asynchronous message passing (or "don't make every particle its own actor").

Regarding applying backpressure, you're correct that Erlang doesn't have a silver bullet. Process mailboxes are unbounded and can exhaust resources. Or you can implement a buffer and drop messages based on some strategy.

As for making every 'operation' asynchronous, you could do it and not run into any additional unbounded queue or error handling problems, but it would add overhead without any advantage over concurrency via preemption.

Erlang has two kinds of 'function calls' (terminology used there is message passing):

- Synchronous calls where the caller will receive a response, and waits for X seconds until considering the message lost. Synchronous messages are blocking on the caller side, and block on the receiever while they are being processed.

- Asynchronous calls where the caller fires the message off and further semantics are undefined---the message could be ignored, lost, received, and acknowledged through a side channel, or a message back to the caller later on.

The Erlang runtime provides a framework--OTP as in online telecom protocol referencing its always on, phones must work at all times roots--that lets you set up supervisors, watchers, and handlers to deal with the problem of trying to send messages to processes that aren't there, child processes disappearing on you, and so forth.

Erlang's ecosystem aims for a 'soft realtime' setup, where usefulness degrades but is not totally lost---so the default option on failure is to retry until some kind of success threshold is reached.

not exactly. Inside an Actor, the Actor model of Hewitt say nothing. You can do whatever you want to decide what you do with the next message.

Reply on news.ycombinator.com