The holes in the cheese

[Douglas Crockford]

Carl was developing an actor hardware architecture. His design incorporated arbiters, which we heard a lot about. I did not see much else. But now I am thinking that he designed Actorscript specifically to fit the constraints of his hardware. He got rid of mailboxes because that was a messy feature at the hardware level. That required that actors explicitly maintain their own queues. That requires holes in the cheese to allow actors to get out of their own ways so that the arbiters can do their thing.

Carl said that the things that I perceived as weirdness in Actorscript were intended to make things easier for the ordinary programmer, a claim that did not make sense to me. I think what he was trying to do was to make his actor hardware accessible to the mainstream, and Actorscript was how he was going to do it.

I have noticed that sometimes very smart people can produce overly complex designs. I think Carl suffered from that. In my own practice, being much less smart, I strive for the simple and minimal. That is about all I can handle.

Did anyone see Carl's hardware architecture? He said he was pitching it to Intel, but I never saw a presentation or documentation.

[Alan Karp]

I have a different understanding.  I believe he got rid of mailboxes because he wanted everything to be an actor.  If that's the case, how can a mailbox have a mailbox?

I did not get the impression that the holes in the cheese had anything to do with handling Actor messages.  I believe he said more than once that the holes allowed concurrency for applications that needed the performance boost, e.g., his readers/writers example.  On the other hand, I believe the arbiters were for handling simultaneously received messages.

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

--
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/b51a4068-dd69-48d7-8d09-3ebb568a8ecan%40googlegroups.com.

[Raoul Duke]

$0.02 iiuc there's the holes in the cheese, and there's the
string-bean styles. Both of which are related to several things, one
of which is message handling. Does an actor do a single threaded
run-to-completion for a message, or can it do some continuation /
concurrency / async / future / promise stuff while handling a given
message (which is about gaining performance/interactivity)?
ActorScript purports to let the actor do that stuff somewhat
automagically iiuc.

(it seems there's a lot of variations on all these themes through the
various actory-esque systems, e.g. as a random aside note that Erlang
says messages must be allowed to be handled out of order from the
incoming queue, for robustness and sanity, according to Ulf Wiger.)


https://arxiv.org/abs/1008.2748
https://arxiv.org/abs/1008.1459
http://lambda-the-ultimate.org/node/4453

[Alan Karp]

An ActorScript Actor has a zone of mutual exclusion.  A message processed completely in that region runs single threaded to completion as in a classic Actor.  However, the processing of a message in the region of mutual exclusion can enter a hole in the cheese, allowing another message to use the region of mutual exclusion.  That feature extends the classic actor model to allow an Actor to process more than one message at a time.  Carl thought that was a good thing because of the potential for improved performance.  I disagreed because of all the errors that could occur with multiple messages being processed concurrently.

I think the Erlang message handling policy makes sense since message order arrival is in general non-deterministic.  Since you can't control what order messages go into the queue, it shouldn't matter in what order you process them.  You might want a different policy if you have different messaging guarantees, such as pairwise in order. 

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

--
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/CAJ7XQb7Q4mgBzTuREDQ2qAC8OzU%3D4N2wLwfs22RqLrRF45qETQ%40mail.gmail.com.

[Douglas Crockford]

Hewittactors could have queues, and the queues were not hewittactors. The same goes for mailboxes. 

[Alan Karp]

I had a conversation with Carl about this a couple of years ago.  As I remember, the messages were delivered to a Heweittactor by a runtime that maintained the queue.  At another time he told me that mailboxes were Hewittactors.  I don't know if his thinking changed between those two discussions.  

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

--

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/501bb993-2c08-41a3-9f95-90f8a95e0bb4n%40googlegroups.com.

[Chip Morningstar]

I had a long talk with him about cheese one time when I was trying to wrap my head around the abstraction, and eventually figured out that rather than implementing a complicated exclusion mechanism you could got the same result using our regular run-to-completion method model and treating each of the exits from a hole back into the cheese as a closely held facet.  After some considerable back and forth, he agreed that this was indeed the case and would simplify the implementation, and then of course proceeded on from there as if this conversation had never happened.  This seems somehow emblematic of many of the conversations I had with him — you’d gain considerable respect from him by showing him he was wrong about something, but he’d still ignore the result!

--
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/b51a4068-dd69-48d7-8d09-3ebb568a8ecan%40googlegroups.com.

[Dale Schumacher]

I concur with your experience, Chip! This occurred several times when I was trying to implement earlier versions of ActorScript.

A few of these interactions have been captured for posterity, including this thread discussing the cheese https://groups.google.com/g/friam/c/gkyth5x75QM/

At one point I considered building a transpiler from ActorScript to Humus, just to illustrate the equivalence you observed.

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/D2140D2F-B65A-4468-AA90-05FBC1B38394%40fudco.com.

[Terry Hayes]

As you may remember, I attempted to translate Carl's "Dealer" example in ActorScript to Humus, so that I could understand some of Carl's ideas about sequencers. As expected, the translation involved creating additional actors to receive intermediate results and continue the computation.  These were definitely in the nature of "private" facets - created by the "main" actor with the ability to continue a previous computation.

At points in the computation, it was necessary to explicitly put an incoming request onto a queue, since there were other actor computations in "holes" that were incompatible with the new request, or the computation could not be completed at the current time (in Dealer, this meant no matching buyer or seller).  Functional (immutable) queues were used for this purpose, with an updated queue becoming part of the state of the actor by BECOMING an action with the new state.

Carl's ActorScript added primitive concepts for these actions as part of the language.  (I think one such construct was something like "HOLE action THROUGH collection".)

I'll note that Dale's uFork spec includes instructions for queues and dictionaries, which both are useful in writing these actor behaviors.  I don't know whether Dale was influenced by Carl or ActorScript, but I do know I understand why the instructions are there because of my attempt to translate Carl's example.

Terry

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