Re: [go-nuts] Interesting "select" examples

[Andrew Harris]

I was surprised looking through old code that I didn't have much in the way 
of "interesting, non-trivial" selects - in every case where I remember 
doing something interesting through a select statement, later versions had 
moved to less interesting selects, more interesting messages from channels 
in the select arms. Non-deterministic selection between a flat list of 
edges is very clear to reason about. Channels of (some carefully composed 
type of functions and channels and tokens etc.) are possible, so messages 
can be pretty interesting.

Generally I think each example could be motivated as a scheduling gadget 
... I briefly looked at some job queueing libraries (temporal.io, asynq) to 
see if they had "interesting" selects, they also looked like they were 
going more towards interesting messages.

-- 
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/91008b35-cdfa-4de5-8ea2-0f536d33363bn%40googlegroups.com.

Re: [go-nuts] Interesting "select" examples

[Bakul Shah]

> On Apr 4, 2023, at 6:20 AM, Jesper Louis Andersen 
>  wrote:
> 
> On Tue, Apr 4, 2023 at 2:22 AM Nigel Tao  > 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.

[go-nuts] Re: Interesting "select" examples

[p...@morth.org]

Sarama's producer might qualify as interesting. 
https://pkg.go.dev/github.com/Shopify/sarama#example-AsyncProducer-Select
You're supposed to produce messages on a channel while simultaneously 
listening for acks (optional) and errors (mandatory) in the same select 
loop.

Regards,
Per Johansson

On Monday, April 3, 2023 at 5:44:43 AM UTC+2 Nigel Tao wrote:

I'm working on a multi-threaded C++ project. We have the equivalent of 
Go's channels, and are considering whether we also need to implement 
the equivalent of Go's select. 

Does anyone have interesting, non-trivial examples of a Go select 
statement in real code? 

By non-trivial, I mean that a lot of the selects that I've seen have 
exactly two cases, one of them doing "real work" and the other being 
either (1) "default" or (2) a timeout/cancel channel (e.g. 
ctx.Done()). 

In our C++ API, our channel send/recv methods already have 
try_send/try_recv equivalents for (1) and a timeout/cancel mechanism 
for (2). 

bcmills' "Rethinking Classical 
Concurrency Patterns" 
(https://drive.google.com/file/d/1nPdvhB0PutEJzdCq5ms6UI58dp50fcAN/view) 
uses select to implement higher level ResourcePool / WorkerPool APIs 
but select is arguably a private implementation detail. While it might 
not be as beautiful under the hood, I think we can already present 
similar APIs using C++'s std::counting_semaphore. 

r's "A Concurrent Window System" 
(https://swtch.com/~rsc/thread/cws.pdf) discusses select'ing from 
separate window, keyboard and mouse channels but this could arguably 
instead be a single channel of heterogenous elements (e.g. in C++, a 
std::variant). 

It's more interesting to select over both input and output channels, 
and output channels may become "ready to communicate" without new 
input. But again, 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. 

The most interesting selects I have so far is the 
golang.org/x/net/http2 source code, whose internals have a bit of a 
learning curve. If anyone has other examples, please share. 

-- 
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/19883d30-cf55-42f1-a2bc-094d240ee22en%40googlegroups.com.

[go-nuts] Re: Disable AVX, AVX2, AVX-512, SSE support while building a go binary

[Uli Kunitz]

After reading the documentation I have to correct.  GO386 supports the 
softfloat option to support older processors which don't support SSE2.
Information can be found 
here: https://github.com/golang/go/wiki/MinimumRequirements#386

On Friday, April 7, 2023 at 8:22:14 AM UTC+2 Uli Kunitz wrote:

> Note that SSE2 is not optional and is used for floating point operations 
> on 386 and AMD64. Before 1.16 there has been a GO386 option that supported 
> 387 instructions but it has been removed. GOAMD64 has no influence on it.
>
> On Thursday, April 6, 2023 at 7:18:03 AM UTC+2 aditi sinha wrote:
>
>> Hi
>>
>> I want to build a simple go binary that prints "hello world" but disablesthe 
>> use of all optional instruction set extensions e.g disable AVX, AVX2, 
>> AVX-512, SSE support .
>>
>> Thanks
>> Aditi
>>
>

-- 
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/da82065f-10f1-4447-9063-78d5c306feafn%40googlegroups.com.

[go-nuts] Re: Disable AVX, AVX2, AVX-512, SSE support while building a go binary

[Uli Kunitz]

Note that SSE2 is not optional and is used for floating point operations on 
386 and AMD64. Before 1.16 there has been a GO386 option that supported 387 
instructions but it has been removed. GOAMD64 has no influence on it.

On Thursday, April 6, 2023 at 7:18:03 AM UTC+2 aditi sinha wrote:

> Hi
>
> I want to build a simple go binary that prints "hello world" but disablesthe 
> use of all optional instruction set extensions e.g disable AVX, AVX2, 
> AVX-512, SSE support .
>
> Thanks
> Aditi
>

-- 
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/3bf8d473-f6d5-4ce2-afe5-4411c6be9c50n%40googlegroups.com.