The Message Is The Medium

[Douglas Crockford]

https://www.youtube.com/watch?v=YD2tnHqNN7w

[Raoul Duke]

i can never find the reference and i always being this up like a broken record but i believe Ulf Wiger suggested that a strongly important pragmatic successful feature of Erlang is that a process (actor) can look ahead in the incoming message buffer, it doesn't have to go in any particular order (ie received timestamp). ... which lets it scan ahead for urgent things. 

On Fri, Oct 6, 2023 at 21:09 Douglas Crockford <dou...@crockford.com> wrote:

https://www.youtube.com/watch?v=YD2tnHqNN7w

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/672440dd-bb5e-4b13-9ad7-47cdf1fa371an%40googlegroups.com.

[Alan Karp]

On Fri, Oct 20, 2023 at 1:45 PM Raoul Duke <rao...@gmail.com> wrote:

i can never find the reference and i always being this up like a broken record but i believe Ulf Wiger suggested that a strongly important pragmatic successful feature of Erlang is that a process (actor) can look ahead in the incoming message buffer, it doesn't have to go in any particular order (ie received timestamp). ... which lets it scan ahead for urgent things. 

Looking ahead in the message buffer was used in the HPC world circa 1990 in PVM and was found to be a mistake.  MPI changed to having multiple message buffers to handle this problem.  I don't know if that insight applies these days or to actor systems.

--------------
Alan Karp

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAJ7XQb5YJQA3z%3D470L0XeXHE-wrG6%3DE8ttYYLexLBFxKHHLwfQ%40mail.gmail.com.

[William ML Leslie]

On Sat, 21 Oct 2023 at 07:12, Alan Karp <alan...@gmail.com> wrote:

On Fri, Oct 20, 2023 at 1:45 PM Raoul Duke <rao...@gmail.com> wrote:

i can never find the reference and i always being this up like a broken record but i believe Ulf Wiger suggested that a strongly important pragmatic successful feature of Erlang is that a process (actor) can look ahead in the incoming message buffer, it doesn't have to go in any particular order (ie received timestamp). ... which lets it scan ahead for urgent things. 

Looking ahead in the message buffer was used in the HPC world circa 1990 in PVM and was found to be a mistake.  MPI changed to having multiple message buffers to handle this problem.  I don't know if that insight applies these days or to actor systems.

There are ways to do priority messaging in actor systems that don't require unbounded memory or linear search.  In Coyotos, for example, when retrieving a message you can either perform a closed wait on a single endpoint id, or you can perform an open wait and listen on all endpoints targeting the process.  Any other process attempting to send you a message will have to wait until you open wait (or wait on the endpoint you are sending to), ensuring that senders are in control of the resources required to send.

I've often wondered - as someone with unfortunately not enough erlang experience - whether the primary cause of crashes in real erlang programs are message buffers mostly full of messages that were never going to be read.  It'd be both a nicer developer experience and lead to more resilient programs if you were restricted somehow to sending messages the target can handle.

--

William ML Leslie

[Douglas Crockford]

I think the requirement for message scanning or message priority is a symptom of poor cohesion, where an actor is doing too much. Such actors should be broken down into many more specialized actors with strong cohesion. 

For example, you can have a secretary actor that receives all messages, and forwards them to the boss actor in priority order. 

[Dale Schumacher]

100% agree with Doug here, but I've been using very fine-grained actors for some time now...

As an example, consider an actor with a continuation-passing-style call-return interface (i.e.: it takes a "customer" to whom it will reply). Now say that in order to service a request it wants to use the services of a couple of other actors. If it wants to be the "customer" for each of these subordinate calls, it must temporarily ignore everyone else. The key observation here is that the call-handler itself is a state-machine with states that represent waiting for each subordinate result.

The solution is to create a work-order actor for each request to the entry-point actor. Then the work-order can "become" each new state until the work is done. At this point it can reply directly to the customer given to the entry-point, or if the entry-point needs to update transactional state, notify the entry-point of the transactional result. If the entry-point must really become "insensitive" during the transaction, it can become an explicit buffering actor (serializer) to hold pending requests. However, the entry-point can also be smarter than that, servicing non-conflicting requests concurrently and/or rejecting inappropriate requests. It can even enforce service-level policies like dropping requests that overflow a policy limit or providing back-pressure, if the API is designed to support that.

--

You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/ec12db4c-3bc1-4478-9b82-601331a200dcn%40googlegroups.com.

[Bill Frantz]

In the KeyKOS model, the Returning to and Entry pattern is a useful possibility:

Returning to an Entry ==> The returner becomes available and the invoked Entry is busy. This pattern allows pipelining. Normally the first Actor in the pipeline receives a Resume key and passes it along the pipeline so the last domain in the pipeline can Return to the caller. Note that it supports parallel execution of service Actors, each working on a separate request to the initial Actor.

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAPeSZfBYWRRe_tLi9e2KgitPXOnPH87JwvPzQdM7f8dEMSogFQ%40mail.gmail.com.