> On Apr 4, 2023, at 6:20 AM, Jesper Louis Andersen > <jesper.louis.ander...@gmail.com> wrote: > > On Tue, Apr 4, 2023 at 2:22 AM Nigel Tao <nigel...@golang.org > <mailto:nigel...@golang.org>> wrote: >> >> I'd have to study mux9p for longer, but its select chooses between two >> receives, so it could possibly collapse to a single heterogenous >> channel. Indeed, both its channels are already heterogenous in some >> sense. Both its processTx and processRx methods say "switch >> m.tx.Type". >> > > If you crank that idea to the max, you can get away with a single mailbox for > a goroutine, much like in the sense Erlang is doing it. This approach, > however, sacrifices type information which is currently being upheld by the > ability to select on multiple channels, each of which have different types. > In my experience, the concurrency primitives are malleable in many > programming languages, and you can implement one model with another, albeit > at a heavy efficiency penalty due to translation.
Note that in Erlang (as well as Hewitt's pure Actor Model) a send never blocks. This means an Erlang process mailbox can grow unbounded (or bounded only by available memory) and you need app specific ways to deal with that. In Go a channel is bounded; which implies a send can block. Nigel Tao wrote in his original message it may be possible to work around that by downstream actors sending "I'm ready to receive" events onto the upstream actor's heterogenous input channel. Which made me wonder if the actors he is talked about are actors in the sense of the Actor Model or Erlang (not the same but close) or if he was using it more generically -- an entity carrying out some action. > I wouldn't be surprised if you find that a simpler model will work in 95% of > all cases, and that you can find workarounds for the remaining 5% to the > point where you are going to ask "what's the point?" I think the answer is > "elegance and simplicity". I would think it is more a question of which model he wants to implement (as why) as Go is based on Hoare's CSP model which is quite different from the Actor concurrency model.... > A view: a select statement is a synchronization of an event. A channel read > or a channel write is an event. The select statement is an algebraic concat > operation, in the sense it takes an array of such events and produces a new > event. We often think of these events as being either "we receive something" > or "we send something". But select-statements also allow for their > combination of "we either send or receive something". Sometimes, serializing > those events into a "send, then receive" or "receive, then send" pattern is > fairly easy. Sometimes, it is exceedingly hard to pull off, and the parallel > send/recv pattern is just that much more elegant and clearer. The key problem > is that sends and/or receives can block, thus obstructing the other event > from being processed. You can alleviate this by tasting each channel through > a poll. But those solutions often end up being convoluted. You can always add more goroutines to avoid selecting over more than one channel! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/EA754B2C-B1C1-4E45-B26E-B3E0D69C2843%40iitbombay.org.
