[go-nuts] expected number of pprof 'total samples'

[Xiangdong Ji]

Hi

I wonder if the expected number of pprof 'total samples' could be 
calculated by:
duration * sample_rate (100HZ) * CPU usage (by 'top')

say if my program's CPU usage reported by 'top' is 200%, and sampling 
period is 30 seconds, could I expect the total samples of pprof is 
approximately:
  30 * 100 * 2  => 6K ?

The formula works well on some physical machines/docker containers, but not 
all of them, sometimes the samples made by pprof is only 50~60% of the 
expected number, that ratio is stable on a specific machine/container.  
Curious to know what could be the rationale behind it?

Thanks.


-- 
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/5f8ca229-1390-46c1-93aa-2840406122a8n%40googlegroups.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Ian Lance Taylor]

On Thu, Apr 29, 2021 at 12:05 PM Øyvind Teig  wrote:
>
> The example here is a server with N clients where it is essential that none 
> of clients will starve and none jam the server. I have needed to do this 
> coding several times. Go has random select which in theory may mean starving 
> and jamming. I worked with safety critical fire detection, and it was 
> necessary to ensure this. Or at least we didn't dare to take the chance. We 
> could not just add another machine.
>
> To use select when that's fair enough (pun 1) - "fair enough" (pun 2). But If 
> I want to be certain of no starving or jamming I need to code the fairness 
> algorithm. I can then promise a client that may have been ready but wasn't 
> served to come in before I take the previous clients that were allowed. This 
> is at best very difficult if all we have is select. Having pri select as the 
> starting point is, in this case, easier.

When there are multiple ready results, the select statement in Go is
guaranteed to use a uniform pseudo-random selection
(https://golang.org/ref/spec#Select_statements).  The fact that cases
are selected using a uniform distribution ensures that executing a
select statement in a loop can't lead to starving (I'm not sure what
jamming is).

As several people have said, it's meaningless to say "I want to ensure
that if both case A and case B are available then the select statement
will choose case A."  It's meaningless because it relies on a notion
of simultaneity that literally doesn't exist.  There will always be a
period of time after the select statement chooses B, but before it
actually executes the case, that case A may become ready.  That will
be true for any possible implementation of select, because select is
not an atomic operation.

Therefore, this code using a hypothetical priority case

select {
case pri <-c1:
case <-c2:
}

can always be rewritten as

select {
case <-c1:
default:
select {
case <-c1:
case <-c2:
}
}

The rewritten select is exactly equivalent to the first.  The only way
that they could not be equivalent would be if select were atomic.

Ian

-- 
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/CAOyqgcWZ5eVbjYFksEUQNb1WcXy9uR8ccfBzJP3XsDYLdiUBVw%40mail.gmail.com.

Re: [go-nuts] TotalAlloc dropped in runtime/metrics

['Michael Knyszek' via golang-nuts]

Hi Marco, https://go-review.googlesource.com/c/go/+/312431 just landed and
should resolve the issue for Go 1.17.

On Tue, Apr 20, 2021 at 3:28 PM Michael Knyszek  wrote:

> Oh, actually, you can compute Mallocs and Frees from allocs-by-size and
> frees-by-size (summing the total # of samples). You can only estimate
> TotalAlloc though, which is genuinely missing.
>
> On Tue, Apr 20, 2021 at 3:14 PM Michael Knyszek 
> wrote:
>
>> Oh gosh, I think TotalAlloc, Mallocs, and Frees are actually an oversight
>> on my part. Sorry about that. They're very easy to add and I can probably
>> even add them for this release.
>>
>> Please do use the new runtime/metrics package!
>>
>> Most of the other metrics should be there in some form (e.g. the
>> divisions are a little different; they're meant to be more orthogonal to
>> each other... GC pause latencies are now in a histogram) and new ones are
>> going to be added in the next release and in the future. Also: today, it
>> does not have the same stop-the-world penalty that ReadMemStats has, so I
>> recommend it on that basis.
>>
>> On Tue, Apr 20, 2021 at 3:08 PM Ian Lance Taylor  wrote:
>>
>>> [ + mknyszek ]
>>>
>>> On Tue, Apr 20, 2021 at 11:12 AM Marco A.  wrote:
>>> >
>>> > Hi everyone,
>>> >
>>> > I was considering using the new stable metrics interface with go 1.16 (
>>> https://golang.org/pkg/runtime/metrics/) for our program and I was also
>>> wondering why things like TotalAlloc (
>>> https://golang.org/pkg/runtime/#MemStats) had been dropped in the
>>> available metrics.
>>> >
>>> > Any particular reasoning behind this?
>>> >
>>> > --
>>> > 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/c12d3534-d0b3-4567-9bc8-7cdcfb63c23cn%40googlegroups.com
>>> .
>>>
>>

-- 
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/CAFza%2Bu_SZRSpeEBHJ904jChgs%3D_Fu_ws8EGG8Zwh2jd174BmLg%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[roger peppe]

On Thu, 29 Apr 2021, 20:05 Øyvind Teig,  wrote:

> torsdag 29. april 2021 kl. 20:22:32 UTC+2 skrev rog:
>
>> I agree with Axel's take here. It seems, Øyvind, that you are concerned
>> more with principle than practice here. Can you give an example of a real
>> world case where you think that this might actually matter?
>>
>
> Thanks, yes. I have written some about that in the *Nondeterminsim* blog
> note, referred to at the top. I admit I indicated that seeing some code
> might be interesting, but it was the principle I was after. In the end a
> "yes" or "no".
>
> Some from the chapter "*-Nondeterministic selective choice in
> implementations is not good*": (Preceeding the quote I have been telling
> about CSP's *external* nondeterministic choice in the *specfications*
> ("implement this any way you want") but in the *implementation* part we
> have to take decisions (deterministic, inner choice: "we do it *this*
> way"). I was thinking this is relevant because Why build concurrency on
> the ideas of CSP?  Here's the quote:
>
> *"The statement was that with the non-deterministic guarded choice in Go,
> what happens is up to the run-time, which is “not good”. This
> is implementation, not specification. With occam there is ALT or PRI ALT,
> always coded as PRI ALT. For a server to be “fair” I have to code it
> myself, it’s up to me, at the application level to find the best algorithm.
> Which, during my years as occam programmer was “new starting channel index
> in the ALT-set is the channel index of the served channel + 1
> modulo-divided by number of channels”. Channels are clients[0..4]
> (five) ALT‘ed in set [4,0,1,2,3] served index 4, then 4+1 rem 5 == 0 yields
> next ALT set [0,1,2,3,4]. Just served 4 and you’re at the back of the set."*
>
> The example here is a server with N clients where it is essential that
> none of clients will starve and none jam the server.
>
I have needed to do this coding several times. Go has random select which
> in theory may mean starving and jamming. I worked with safety critical fire
> detection, and it was necessary to ensure this. Or at least we didn't dare
> to take the chance. We could not just add another machine.
>
> To use select when that's fair enough (pun 1) - "fair enough" (pun 2). But
> If I want to be certain of no starving or jamming I need to code the
> fairness algorithm. I can then promise a client that may have been ready
> but wasn't served to come in before I take the previous clients that were
> allowed. This is at best very difficult if all we have is select. Having
> pri select as the starting point is, in this case, easier.
>

To start with, if you've got N clients where N isn't known in advance, it's
not possible to use Go's select statement directly because it doesn't
provide support for reading from a slice.
You can do it with reflection though. It's not too hard to code something
quite similar to your algorithm above.
For example: https://go2goplay.golang.org/p/S_5WFkpqMP_H

I think the above code should fit your definition of fairness, and it seems
to me that it's a reasonably general approach.

  cheers,
rog.

Øyvind
>
>
>>
>> On Thu, 29 Apr 2021, 15:44 'Axel Wagner' via golang-nuts, <
>> golan...@googlegroups.com> wrote:
>>
>>> FWIW, maybe this helps:
>>>
>>> Assume a read happened from lowPriority, even though highPriority was
>>> ready to read as well. That's, AIUI, the outcome you are concerned about.
>>>
>>> In that situation, how would you know that highPriority was ready to
>>> read as well?
>>>
>>> On Thu, Apr 29, 2021 at 4:39 PM Axel Wagner 
>>> wrote:
>>>
 On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig 
 wrote:

> They could still both have become ready (not in the same "cycle")
> between the two selects. Even if that probability is low, it would need
> knowledge like yours to show that this may in fact be zero. There could be
> a descheduling in between, one of those in my opinion, not relevant
> arguments.


 FTR, again: Yes, it's definitely possible, but it's irrelevant. It
 makes no observable difference. Even if we had a prioritized select, it
 would still be *de facto* implemented as a multi-step process and even
 then, you might run into exactly the same situation - you could have both
 channels becoming ready while the runtime does setup, or you could have a
 random scheduling event delaying one of the goroutines infinitesimally, or
 you could have…

 This is why we *don't* talk about the behavior of concurrent programs
 in terms of cycles and time, but instead based on causal order. We don't
 know how long it takes to park or unpark a goroutine, so all we can say is
 that a read from a channel happens after the corresponding write. In terms
 of time, between entering the `select` statement and between parking the
 goroutine might lie a nanosecond, or a million years - we don't know, so we
 d

Re: [go-nuts] Still "missing" priority or ordered select in go?

['Axel Wagner' via golang-nuts]

On Thu, Apr 29, 2021 at 10:47 PM Øyvind Teig 
wrote:

>
>1. I'm sorry I didn't follow up on your answer where you had got to
>the length of spelling out some code right before my eyes. I got lost in
>the other points (I actually started a response..)
>2. I trust you
>3. But to do more than trusting, understanding would be much better.
>I'm sorry: to understand I would need more than pseudo code
>4. But I was really after whether the "pri" keyword (or whatever) in
>front of "select" had been introduced over the last years. The answer seems
>to be "no"
>
>
FWIW I did answer this explicitly above :) No, there is no way to manually
specify priorities of `select` and no, I subjectively wouldn't predict it
happening at any point in the near or far future. Unless someone comes up
with an extremely convincing, so far unheard of argument in its favor :)


>
>1. Although I appreciate that Turing proved that any language can code
>anything, I some times have had a hard time believing it. Maybe that's not
>exactly what he meant. But then, since I trust you, I do find that solution
>as surprising as as I would be happy to run it on The Go Playground
>
> torsdag 29. april 2021 kl. 22:02:23 UTC+2 skrev ren...@ix.netcom.com:
>
>> I already gave you the solution to this. Trust me it works. I did HFT for
>> 7+ years - the algo is well known.
>>
>> On Apr 29, 2021, at 2:05 PM, Øyvind Teig  wrote:
>>
>> 
>>
>> torsdag 29. april 2021 kl. 20:22:32 UTC+2 skrev rog:
>>
>>> I agree with Axel's take here. It seems, Øyvind, that you are concerned
>>> more with principle than practice here. Can you give an example of a real
>>> world case where you think that this might actually matter?
>>>
>>
>> Thanks, yes. I have written some about that in the *Nondeterminsim* blog
>> note, referred to at the top. I admit I indicated that seeing some code
>> might be interesting, but it was the principle I was after. In the end a
>> "yes" or "no".
>>
>> Some from the chapter "*-Nondeterministic selective choice in
>> implementations is not good*": (Preceeding the quote I have been telling
>> about CSP's *external* nondeterministic choice in the *specfications*
>> ("implement this any way you want") but in the *implementation* part we
>> have to take decisions (deterministic, inner choice: "we do it *this*
>> way"). I was thinking this is relevant because Why build concurrency on
>> the ideas of CSP?  Here's the quote:
>>
>> *"The statement was that with the non-deterministic guarded choice in Go,
>> what happens is up to the run-time, which is “not good”. This
>> is implementation, not specification. With occam there is ALT or PRI ALT,
>> always coded as PRI ALT. For a server to be “fair” I have to code it
>> myself, it’s up to me, at the application level to find the best algorithm.
>> Which, during my years as occam programmer was “new starting channel index
>> in the ALT-set is the channel index of the served channel + 1
>> modulo-divided by number of channels”. Channels are clients[0..4]
>> (five) ALT‘ed in set [4,0,1,2,3] served index 4, then 4+1 rem 5 == 0 yields
>> next ALT set [0,1,2,3,4]. Just served 4 and you’re at the back of the set."*
>>
>> The example here is a server with N clients where it is essential that
>> none of clients will starve and none jam the server. I have needed to do
>> this coding several times. Go has random select which in theory may mean
>> starving and jamming. I worked with safety critical fire detection, and it
>> was necessary to ensure this. Or at least we didn't dare to take the
>> chance. We could not just add another machine.
>>
>> To use select when that's fair enough (pun 1) - "fair enough" (pun 2).
>> But If I want to be certain of no starving or jamming I need to code the
>> fairness algorithm. I can then promise a client that may have been ready
>> but wasn't served to come in before I take the previous clients that were
>> allowed. This is at best very difficult if all we have is select. Having
>> pri select as the starting point is, in this case, easier.
>>
>> Øyvind
>>
>>
>>>
>>> On Thu, 29 Apr 2021, 15:44 'Axel Wagner' via golang-nuts, <
>>> golan...@googlegroups.com> wrote:
>>>
 FWIW, maybe this helps:

 Assume a read happened from lowPriority, even though highPriority was
 ready to read as well. That's, AIUI, the outcome you are concerned about.

 In that situation, how would you know that highPriority was ready to
 read as well?

 On Thu, Apr 29, 2021 at 4:39 PM Axel Wagner 
 wrote:

> On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig 
> wrote:
>
>> They could still both have become ready (not in the same "cycle")
>> between the two selects. Even if that probability is low, it would need
>> knowledge like yours to show that this may in fact be zero. There could 
>> be
>> a descheduling in between, one of those in my opinion, not relevant
>>>

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

   
   1. I'm sorry I didn't follow up on your answer where you had got to the 
   length of spelling out some code right before my eyes. I got lost in the 
   other points (I actually started a response..)
   2. I trust you
   3. But to do more than trusting, understanding would be much better. I'm 
   sorry: to understand I would need more than pseudo code
   4. But I was really after whether the "pri" keyword (or whatever) in 
   front of "select" had been introduced over the last years. The answer seems 
   to be "no"
   5. Although I appreciate that Turing proved that any language can code 
   anything, I some times have had a hard time believing it. Maybe that's not 
   exactly what he meant. But then, since I trust you, I do find that solution 
   as surprising as as I would be happy to run it on The Go Playground

torsdag 29. april 2021 kl. 22:02:23 UTC+2 skrev ren...@ix.netcom.com:

> I already gave you the solution to this. Trust me it works. I did HFT for 
> 7+ years - the algo is well known. 
>
> On Apr 29, 2021, at 2:05 PM, Øyvind Teig  wrote:
>
> 
>
> torsdag 29. april 2021 kl. 20:22:32 UTC+2 skrev rog:
>
>> I agree with Axel's take here. It seems, Øyvind, that you are concerned 
>> more with principle than practice here. Can you give an example of a real 
>> world case where you think that this might actually matter?
>>
>
> Thanks, yes. I have written some about that in the *Nondeterminsim* blog 
> note, referred to at the top. I admit I indicated that seeing some code 
> might be interesting, but it was the principle I was after. In the end a 
> "yes" or "no".
>
> Some from the chapter "*-Nondeterministic selective choice in 
> implementations is not good*": (Preceeding the quote I have been telling 
> about CSP's *external* nondeterministic choice in the *specfications* 
> ("implement this any way you want") but in the *implementation* part we 
> have to take decisions (deterministic, inner choice: "we do it *this* 
> way"). I was thinking this is relevant because Why build concurrency on 
> the ideas of CSP?  Here's the quote:
>
> *"The statement was that with the non-deterministic guarded choice in Go, 
> what happens is up to the run-time, which is “not good”. This 
> is implementation, not specification. With occam there is ALT or PRI ALT, 
> always coded as PRI ALT. For a server to be “fair” I have to code it 
> myself, it’s up to me, at the application level to find the best algorithm. 
> Which, during my years as occam programmer was “new starting channel index 
> in the ALT-set is the channel index of the served channel + 1 
> modulo-divided by number of channels”. Channels are clients[0..4] 
> (five) ALT‘ed in set [4,0,1,2,3] served index 4, then 4+1 rem 5 == 0 yields 
> next ALT set [0,1,2,3,4]. Just served 4 and you’re at the back of the set."*
>
> The example here is a server with N clients where it is essential that 
> none of clients will starve and none jam the server. I have needed to do 
> this coding several times. Go has random select which in theory may mean 
> starving and jamming. I worked with safety critical fire detection, and it 
> was necessary to ensure this. Or at least we didn't dare to take the 
> chance. We could not just add another machine.
>
> To use select when that's fair enough (pun 1) - "fair enough" (pun 2). But 
> If I want to be certain of no starving or jamming I need to code the 
> fairness algorithm. I can then promise a client that may have been ready 
> but wasn't served to come in before I take the previous clients that were 
> allowed. This is at best very difficult if all we have is select. Having 
> pri select as the starting point is, in this case, easier.
>
> Øyvind
>  
>
>>
>> On Thu, 29 Apr 2021, 15:44 'Axel Wagner' via golang-nuts, <
>> golan...@googlegroups.com> wrote:
>>
>>> FWIW, maybe this helps:
>>>
>>> Assume a read happened from lowPriority, even though highPriority was 
>>> ready to read as well. That's, AIUI, the outcome you are concerned about.
>>>
>>> In that situation, how would you know that highPriority was ready to 
>>> read as well?
>>>
>>> On Thu, Apr 29, 2021 at 4:39 PM Axel Wagner  
>>> wrote:
>>>
 On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig  
 wrote:

> They could still both have become ready (not in the same "cycle") 
> between the two selects. Even if that probability is low, it would need 
> knowledge like yours to show that this may in fact be zero. There could 
> be 
> a descheduling in between, one of those in my opinion, not relevant 
> arguments.


 FTR, again: Yes, it's definitely possible, but it's irrelevant. It 
 makes no observable difference. Even if we had a prioritized select, it 
 would still be *de facto* implemented as a multi-step process and even 
 then, you might run into exactly the same situation - you could have both 
 channels becoming ready while the runtime does setup, or you could have a 
>

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Robert Engels]

I already gave you the solution to this. Trust me it works. I did HFT for 7+ 
years - the algo is well known. 

> On Apr 29, 2021, at 2:05 PM, Øyvind Teig  wrote:
> 
> 
>> torsdag 29. april 2021 kl. 20:22:32 UTC+2 skrev rog:
> 
>> I agree with Axel's take here. It seems, Øyvind, that you are concerned more 
>> with principle than practice here. Can you give an example of a real world 
>> case where you think that this might actually matter?
> 
> Thanks, yes. I have written some about that in the Nondeterminsim blog note, 
> referred to at the top. I admit I indicated that seeing some code might be 
> interesting, but it was the principle I was after. In the end a "yes" or "no".
> 
> Some from the chapter "-Nondeterministic selective choice in implementations 
> is not good": (Preceeding the quote I have been telling about CSP's external 
> nondeterministic choice in the specfications ("implement this any way you 
> want") but in the implementation part we have to take decisions 
> (deterministic, inner choice: "we do it this way"). I was thinking this is 
> relevant because Why build concurrency on the ideas of CSP? Here's the quote:
> 
> "The statement was that with the non-deterministic guarded choice in Go, what 
> happens is up to the run-time, which is “not good”. This is implementation, 
> not specification. With occam there is ALT or PRI ALT, always coded as PRI 
> ALT. For a server to be “fair” I have to code it myself, it’s up to me, at 
> the application level to find the best algorithm. Which, during my years as 
> occam programmer was “new starting channel index in the ALT-set is the 
> channel index of the served channel + 1 modulo-divided by number of 
> channels”. Channels are clients[0..4] (five) ALT‘ed in set [4,0,1,2,3] served 
> index 4, then 4+1 rem 5 == 0 yields next ALT set [0,1,2,3,4]. Just served 4 
> and you’re at the back of the set."
> 
> The example here is a server with N clients where it is essential that none 
> of clients will starve and none jam the server. I have needed to do this 
> coding several times. Go has random select which in theory may mean starving 
> and jamming. I worked with safety critical fire detection, and it was 
> necessary to ensure this. Or at least we didn't dare to take the chance. We 
> could not just add another machine.
> 
> To use select when that's fair enough (pun 1) - "fair enough" (pun 2). But If 
> I want to be certain of no starving or jamming I need to code the fairness 
> algorithm. I can then promise a client that may have been ready but wasn't 
> served to come in before I take the previous clients that were allowed. This 
> is at best very difficult if all we have is select. Having pri select as the 
> starting point is, in this case, easier.
> 
> Øyvind
>  
>> 
>>> On Thu, 29 Apr 2021, 15:44 'Axel Wagner' via golang-nuts, 
>>>  wrote:
>>> FWIW, maybe this helps:
>>> 
>>> Assume a read happened from lowPriority, even though highPriority was ready 
>>> to read as well. That's, AIUI, the outcome you are concerned about.
>>> 
>>> In that situation, how would you know that highPriority was ready to read 
>>> as well?
>>> 
 On Thu, Apr 29, 2021 at 4:39 PM Axel Wagner  
 wrote:
> On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig  wrote:
 
> They could still both have become ready (not in the same "cycle") between 
> the two selects. Even if that probability is low, it would need knowledge 
> like yours to show that this may in fact be zero. There could be a 
> descheduling in between, one of those in my opinion, not relevant 
> arguments.
 
 FTR, again: Yes, it's definitely possible, but it's irrelevant. It makes 
 no observable difference. Even if we had a prioritized select, it would 
 still be *de facto* implemented as a multi-step process and even then, you 
 might run into exactly the same situation - you could have both channels 
 becoming ready while the runtime does setup, or you could have a random 
 scheduling event delaying one of the goroutines infinitesimally, or you 
 could have…
 
 This is why we *don't* talk about the behavior of concurrent programs in 
 terms of cycles and time, but instead based on causal order. We don't know 
 how long it takes to park or unpark a goroutine, so all we can say is that 
 a read from a channel happens after the corresponding write. In terms of 
 time, between entering the `select` statement and between parking the 
 goroutine might lie a nanosecond, or a million years - we don't know, so 
 we don't talk about it.
 
 The memory model is exactly there to abstract away these differences and 
 to not get caught up in scheduling and cycle discussions - so, FWIW, if 
 these arguments are not relevant, you shouldn't bring them up. Logically, 
 between the first `select` statement and the second `select` statement, 
 there is zero time happening. Arguing that there is, is using exac

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

torsdag 29. april 2021 kl. 20:22:32 UTC+2 skrev rog:

> I agree with Axel's take here. It seems, Øyvind, that you are concerned 
> more with principle than practice here. Can you give an example of a real 
> world case where you think that this might actually matter?
>

Thanks, yes. I have written some about that in the *Nondeterminsim* blog 
note, referred to at the top. I admit I indicated that seeing some code 
might be interesting, but it was the principle I was after. In the end a 
"yes" or "no".

Some from the chapter "*-Nondeterministic selective choice in 
implementations is not good*": (Preceeding the quote I have been telling 
about CSP's *external* nondeterministic choice in the *specfications* 
("implement this any way you want") but in the *implementation* part we 
have to take decisions (deterministic, inner choice: "we do it *this* 
way"). I was thinking this is relevant because Why build concurrency on the 
ideas of CSP?  Here's the quote:

*"The statement was that with the non-deterministic guarded choice in Go, 
what happens is up to the run-time, which is “not good”. This 
is implementation, not specification. With occam there is ALT or PRI ALT, 
always coded as PRI ALT. For a server to be “fair” I have to code it 
myself, it’s up to me, at the application level to find the best algorithm. 
Which, during my years as occam programmer was “new starting channel index 
in the ALT-set is the channel index of the served channel + 1 
modulo-divided by number of channels”. Channels are clients[0..4] 
(five) ALT‘ed in set [4,0,1,2,3] served index 4, then 4+1 rem 5 == 0 yields 
next ALT set [0,1,2,3,4]. Just served 4 and you’re at the back of the set."*

The example here is a server with N clients where it is essential that none 
of clients will starve and none jam the server. I have needed to do this 
coding several times. Go has random select which in theory may mean 
starving and jamming. I worked with safety critical fire detection, and it 
was necessary to ensure this. Or at least we didn't dare to take the 
chance. We could not just add another machine.

To use select when that's fair enough (pun 1) - "fair enough" (pun 2). But 
If I want to be certain of no starving or jamming I need to code the 
fairness algorithm. I can then promise a client that may have been ready 
but wasn't served to come in before I take the previous clients that were 
allowed. This is at best very difficult if all we have is select. Having 
pri select as the starting point is, in this case, easier.

Øyvind
 

>
> On Thu, 29 Apr 2021, 15:44 'Axel Wagner' via golang-nuts, <
> golan...@googlegroups.com> wrote:
>
>> FWIW, maybe this helps:
>>
>> Assume a read happened from lowPriority, even though highPriority was 
>> ready to read as well. That's, AIUI, the outcome you are concerned about.
>>
>> In that situation, how would you know that highPriority was ready to read 
>> as well?
>>
>> On Thu, Apr 29, 2021 at 4:39 PM Axel Wagner  
>> wrote:
>>
>>> On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig  
>>> wrote:
>>>
 They could still both have become ready (not in the same "cycle") 
 between the two selects. Even if that probability is low, it would need 
 knowledge like yours to show that this may in fact be zero. There could be 
 a descheduling in between, one of those in my opinion, not relevant 
 arguments.
>>>
>>>
>>> FTR, again: Yes, it's definitely possible, but it's irrelevant. It makes 
>>> no observable difference. Even if we had a prioritized select, it would 
>>> still be *de facto* implemented as a multi-step process and even then, you 
>>> might run into exactly the same situation - you could have both channels 
>>> becoming ready while the runtime does setup, or you could have a random 
>>> scheduling event delaying one of the goroutines infinitesimally, or you 
>>> could have…
>>>
>>> This is why we *don't* talk about the behavior of concurrent programs in 
>>> terms of cycles and time, but instead based on causal order. We don't know 
>>> how long it takes to park or unpark a goroutine, so all we can say is that 
>>> a read from a channel happens after the corresponding write. In terms of 
>>> time, between entering the `select` statement and between parking the 
>>> goroutine might lie a nanosecond, or a million years - we don't know, so we 
>>> don't talk about it.
>>>
>>> The memory model is exactly there to abstract away these differences and 
>>> to not get caught up in scheduling and cycle discussions - so, FWIW, if 
>>> these arguments are not relevant, you shouldn't bring them up. Logically, 
>>> between the first `select` statement and the second `select` statement, 
>>> there is zero time happening. Arguing that there is, is using exactly those 
>>> irrelevant arguments about schedulers and processing time.
>>>  
>>>
 torsdag 29. april 2021 kl. 15:47:42 UTC+2 skrev Jan Mercl:

> On Thu, Apr 29, 2021 at 3:23 PM Øyvind Teig  
> wrote: 

Re: [go-nuts] Still "missing" priority or ordered select in go?

[roger peppe]

I agree with Axel's take here. It seems, Øyvind, that you are concerned
more with principle than practice here. Can you give an example of a real
world case where you think that this might actually matter?

On Thu, 29 Apr 2021, 15:44 'Axel Wagner' via golang-nuts, <
golang-nuts@googlegroups.com> wrote:

> FWIW, maybe this helps:
>
> Assume a read happened from lowPriority, even though highPriority was
> ready to read as well. That's, AIUI, the outcome you are concerned about.
>
> In that situation, how would you know that highPriority was ready to read
> as well?
>
> On Thu, Apr 29, 2021 at 4:39 PM Axel Wagner 
> wrote:
>
>> On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig 
>> wrote:
>>
>>> They could still both have become ready (not in the same "cycle")
>>> between the two selects. Even if that probability is low, it would need
>>> knowledge like yours to show that this may in fact be zero. There could be
>>> a descheduling in between, one of those in my opinion, not relevant
>>> arguments.
>>
>>
>> FTR, again: Yes, it's definitely possible, but it's irrelevant. It makes
>> no observable difference. Even if we had a prioritized select, it would
>> still be *de facto* implemented as a multi-step process and even then, you
>> might run into exactly the same situation - you could have both channels
>> becoming ready while the runtime does setup, or you could have a random
>> scheduling event delaying one of the goroutines infinitesimally, or you
>> could have…
>>
>> This is why we *don't* talk about the behavior of concurrent programs in
>> terms of cycles and time, but instead based on causal order. We don't know
>> how long it takes to park or unpark a goroutine, so all we can say is that
>> a read from a channel happens after the corresponding write. In terms of
>> time, between entering the `select` statement and between parking the
>> goroutine might lie a nanosecond, or a million years - we don't know, so we
>> don't talk about it.
>>
>> The memory model is exactly there to abstract away these differences and
>> to not get caught up in scheduling and cycle discussions - so, FWIW, if
>> these arguments are not relevant, you shouldn't bring them up. Logically,
>> between the first `select` statement and the second `select` statement,
>> there is zero time happening. Arguing that there is, is using exactly those
>> irrelevant arguments about schedulers and processing time.
>>
>>
>>> torsdag 29. april 2021 kl. 15:47:42 UTC+2 skrev Jan Mercl:
>>>
 On Thu, Apr 29, 2021 at 3:23 PM Øyvind Teig 
 wrote:

 > 4c is not "correct" as I want it. In the pri select case, if more
 than one is ready, then they shall not be randomly chosen. Never. They
 should be selected according to priority.

 That's not what 4c says. Instead of "more than one ready" it says
 "both high and low _get ready at the same time_".

 Note that in the first approximation the probability of 4c happening
 is approaching zero. If we consider time "ticks" in discrete quanta,
 the probability is proportional to the size of the quantum. And
 depending on a particular implementation of the scheduler the
 probability of 4c can still be exactly zero. For example, the OS
 kernel may deliver only one signal at a time to the process etc.

 So the "Never" case may quite well never happen at all.

>>> --
>>> 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/2460a16f-af1b-4613-ba4a-72b13e816a2bn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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/CAEkBMfFC1gtxbWZsy88gM4ymPncCjs6Q3YJpTcXym8bT1Ev6Kw%40mail.gmail.com
> 
> .
>

-- 
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/CAJhgachVuBduF_ucmywVKfDM4On05ekNEgxGPmHgWm0V6xFDxw%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

['Axel Wagner' via golang-nuts]

FWIW, maybe this helps:

Assume a read happened from lowPriority, even though highPriority was ready
to read as well. That's, AIUI, the outcome you are concerned about.

In that situation, how would you know that highPriority was ready to read
as well?

On Thu, Apr 29, 2021 at 4:39 PM Axel Wagner 
wrote:

> On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig 
> wrote:
>
>> They could still both have become ready (not in the same "cycle") between
>> the two selects. Even if that probability is low, it would need knowledge
>> like yours to show that this may in fact be zero. There could be a
>> descheduling in between, one of those in my opinion, not relevant arguments.
>
>
> FTR, again: Yes, it's definitely possible, but it's irrelevant. It makes
> no observable difference. Even if we had a prioritized select, it would
> still be *de facto* implemented as a multi-step process and even then, you
> might run into exactly the same situation - you could have both channels
> becoming ready while the runtime does setup, or you could have a random
> scheduling event delaying one of the goroutines infinitesimally, or you
> could have…
>
> This is why we *don't* talk about the behavior of concurrent programs in
> terms of cycles and time, but instead based on causal order. We don't know
> how long it takes to park or unpark a goroutine, so all we can say is that
> a read from a channel happens after the corresponding write. In terms of
> time, between entering the `select` statement and between parking the
> goroutine might lie a nanosecond, or a million years - we don't know, so we
> don't talk about it.
>
> The memory model is exactly there to abstract away these differences and
> to not get caught up in scheduling and cycle discussions - so, FWIW, if
> these arguments are not relevant, you shouldn't bring them up. Logically,
> between the first `select` statement and the second `select` statement,
> there is zero time happening. Arguing that there is, is using exactly those
> irrelevant arguments about schedulers and processing time.
>
>
>> torsdag 29. april 2021 kl. 15:47:42 UTC+2 skrev Jan Mercl:
>>
>>> On Thu, Apr 29, 2021 at 3:23 PM Øyvind Teig 
>>> wrote:
>>>
>>> > 4c is not "correct" as I want it. In the pri select case, if more than
>>> one is ready, then they shall not be randomly chosen. Never. They should be
>>> selected according to priority.
>>>
>>> That's not what 4c says. Instead of "more than one ready" it says
>>> "both high and low _get ready at the same time_".
>>>
>>> Note that in the first approximation the probability of 4c happening
>>> is approaching zero. If we consider time "ticks" in discrete quanta,
>>> the probability is proportional to the size of the quantum. And
>>> depending on a particular implementation of the scheduler the
>>> probability of 4c can still be exactly zero. For example, the OS
>>> kernel may deliver only one signal at a time to the process etc.
>>>
>>> So the "Never" case may quite well never happen at all.
>>>
>> --
>> 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/2460a16f-af1b-4613-ba4a-72b13e816a2bn%40googlegroups.com
>> 
>> .
>>
>

-- 
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/CAEkBMfFC1gtxbWZsy88gM4ymPncCjs6Q3YJpTcXym8bT1Ev6Kw%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

['Axel Wagner' via golang-nuts]

On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig  wrote:

> They could still both have become ready (not in the same "cycle") between
> the two selects. Even if that probability is low, it would need knowledge
> like yours to show that this may in fact be zero. There could be a
> descheduling in between, one of those in my opinion, not relevant arguments.


FTR, again: Yes, it's definitely possible, but it's irrelevant. It makes no
observable difference. Even if we had a prioritized select, it would still
be *de facto* implemented as a multi-step process and even then, you might
run into exactly the same situation - you could have both channels becoming
ready while the runtime does setup, or you could have a random scheduling
event delaying one of the goroutines infinitesimally, or you could have…

This is why we *don't* talk about the behavior of concurrent programs in
terms of cycles and time, but instead based on causal order. We don't know
how long it takes to park or unpark a goroutine, so all we can say is that
a read from a channel happens after the corresponding write. In terms of
time, between entering the `select` statement and between parking the
goroutine might lie a nanosecond, or a million years - we don't know, so we
don't talk about it.

The memory model is exactly there to abstract away these differences and to
not get caught up in scheduling and cycle discussions - so, FWIW, if these
arguments are not relevant, you shouldn't bring them up. Logically, between
the first `select` statement and the second `select` statement, there is
zero time happening. Arguing that there is, is using exactly those
irrelevant arguments about schedulers and processing time.


> torsdag 29. april 2021 kl. 15:47:42 UTC+2 skrev Jan Mercl:
>
>> On Thu, Apr 29, 2021 at 3:23 PM Øyvind Teig 
>> wrote:
>>
>> > 4c is not "correct" as I want it. In the pri select case, if more than
>> one is ready, then they shall not be randomly chosen. Never. They should be
>> selected according to priority.
>>
>> That's not what 4c says. Instead of "more than one ready" it says
>> "both high and low _get ready at the same time_".
>>
>> Note that in the first approximation the probability of 4c happening
>> is approaching zero. If we consider time "ticks" in discrete quanta,
>> the probability is proportional to the size of the quantum. And
>> depending on a particular implementation of the scheduler the
>> probability of 4c can still be exactly zero. For example, the OS
>> kernel may deliver only one signal at a time to the process etc.
>>
>> So the "Never" case may quite well never happen at all.
>>
> --
> 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/2460a16f-af1b-4613-ba4a-72b13e816a2bn%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfHynmh9_RDSfEw3G8SXwfuABfdXrn_yVxmKifwz_cUTKA%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[robert engels]

To clarify, you might never process a low item if a high is always available - 
but I believe that is what the OP is requesting.

It is also fairly trivial to add fairness to this ti always process a low if 
available every N cycles.

> On Apr 29, 2021, at 9:31 AM, robert engels  wrote:
> 
> It is not.
> 
> Because the low items will be read if there are no highs available. If the 
> low isn’t read, the producer on the low will block.
> 
> Or you run out of memory if you cannot process the events fast enough - which 
> is also easily handled by bounding the queue - but then you may need to drop 
> items.
> 
> There are no free lunches.
> 
> But no deadlock.
> 
> 
> 
>> On Apr 29, 2021, at 9:26 AM, Ian Davis > > wrote:
>> 
>> On Thu, 29 Apr 2021, at 3:09 PM, robert engels wrote:
>>> I will give you the pseudo code:
>>> 
>>> { // step #1 do select on both
>>>select high
>>>select low
>>> }
>>> 
>>> if high read:
>>>return high
>>> else:
>>>// we read a low so do a high poll
>>>{
>>>select high:
>>>default:
>>>}
>>> 
>>>  if high read:
>>>   enqueue low and return high
>>>  else:
>>>   if queue empty:
>>>  return low
>>>   else:
>>>use queue and enqueue low from step #1 // FIFO order on low 
>>> reads 
>>> 
>>> The above code will always return high values over low values (if high 
>>> available), and return low values in order of events
>> 
>> This seems likely deadlock if the low channel is being filled continually by 
>> another goroutine. In addition I usually aim to give ownership of the 
>> channel to the writer so it can close cleanly, but mixing reads and writes 
>> in a single function greatly complicates that.
>> 
>> Ian
>> 
>> -- 
>> 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/f26ee7f2-a518-433f-89d4-d55aa0a9b07d%40www.fastmail.com
>>  
>> .
> 
> 
> -- 
> 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/00218548-6E27-4E16-A75F-88B6E30195E5%40ix.netcom.com
>  
> .

-- 
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/10A8C321-E56E-43D2-8E00-C95AF52AD1E8%40ix.netcom.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[robert engels]

It is not.

Because the low items will be read if there are no highs available. If the low 
isn’t read, the producer on the low will block.

Or you run out of memory if you cannot process the events fast enough - which 
is also easily handled by bounding the queue - but then you may need to drop 
items.

There are no free lunches.

But no deadlock.



> On Apr 29, 2021, at 9:26 AM, Ian Davis  wrote:
> 
> On Thu, 29 Apr 2021, at 3:09 PM, robert engels wrote:
>> I will give you the pseudo code:
>> 
>> { // step #1 do select on both
>>select high
>>select low
>> }
>> 
>> if high read:
>>return high
>> else:
>>// we read a low so do a high poll
>>{
>>select high:
>>default:
>>}
>> 
>>  if high read:
>>   enqueue low and return high
>>  else:
>>   if queue empty:
>>  return low
>>   else:
>>use queue and enqueue low from step #1 // FIFO order on low reads 
>> 
>> The above code will always return high values over low values (if high 
>> available), and return low values in order of events
> 
> This seems likely deadlock if the low channel is being filled continually by 
> another goroutine. In addition I usually aim to give ownership of the channel 
> to the writer so it can close cleanly, but mixing reads and writes in a 
> single function greatly complicates that.
> 
> Ian
> 
> -- 
> 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/f26ee7f2-a518-433f-89d4-d55aa0a9b07d%40www.fastmail.com
>  
> .

-- 
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/00218548-6E27-4E16-A75F-88B6E30195E5%40ix.netcom.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[robert engels]

It needs one other fix, and that is to have a check of the queue and poll high, 
in case the queue has elements when the method is entered.

But if you implement the queue using a buffered channel it is trivial to change 
the step #1 to handle this (the low and queue channels are mimic the high and 
low channel).

> On Apr 29, 2021, at 8:53 AM, Øyvind Teig  wrote:
> 
> 
> They could still both have become ready (not in the same "cycle") between the 
> two selects. Even if that probability is low, it would need knowledge like 
> yours to show that this may in fact be zero. There could be a descheduling in 
> between, one of those in my opinion, not relevant arguments.
> torsdag 29. april 2021 kl. 15:47:42 UTC+2 skrev Jan Mercl:
> On Thu, Apr 29, 2021 at 3:23 PM Øyvind Teig  > wrote: 
> 
> > 4c is not "correct" as I want it. In the pri select case, if more than one 
> > is ready, then they shall not be randomly chosen. Never. They should be 
> > selected according to priority. 
> 
> That's not what 4c says. Instead of "more than one ready" it says 
> "both high and low _get ready at the same time_". 
> 
> Note that in the first approximation the probability of 4c happening 
> is approaching zero. If we consider time "ticks" in discrete quanta, 
> the probability is proportional to the size of the quantum. And 
> depending on a particular implementation of the scheduler the 
> probability of 4c can still be exactly zero. For example, the OS 
> kernel may deliver only one signal at a time to the process etc. 
> 
> So the "Never" case may quite well never happen at all. 
> 
> -- 
> 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/2460a16f-af1b-4613-ba4a-72b13e816a2bn%40googlegroups.com
>  
> .

-- 
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/0849008D-FD08-4796-9D4B-D43316229F43%40ix.netcom.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Ian Davis]

On Thu, 29 Apr 2021, at 3:09 PM, robert engels wrote:
> I will give you the pseudo code:
> 
> { // step #1 do select on both
>select high
>select low
> }
> 
> if high read:
>return high
> else:
>// we read a low so do a high poll
>{
>select high:
>default:
>}
> 
>  if high read:
>   enqueue low and return high
>  else:
>   if queue empty:
>  return low
>   else:
>use queue and enqueue low from step #1 // FIFO order on low reads 
> 
> The above code will always return high values over low values (if high 
> available), and return low values in order of events

This seems likely deadlock if the low channel is being filled continually by 
another goroutine. In addition I usually aim to give ownership of the channel 
to the writer so it can close cleanly, but mixing reads and writes in a single 
function greatly complicates that.

Ian

-- 
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/f26ee7f2-a518-433f-89d4-d55aa0a9b07d%40www.fastmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Jan Mercl]

On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig  wrote:

> Even if that probability is low, it would need knowledge like yours to show 
> that this may in fact be zero. There could be a descheduling in between, one 
> of those in my opinion, not relevant arguments.

The upper limit of 4c happening is 1/12 for random events. I guess in
practice it is at least an order of magnitude lower because the
"effective" time ticks are small.

-- 
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/CAA40n-VAjeUCokuLHFnBf15Gn7ksbhc6z_oi-bY-qEFbj0vWHw%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[robert engels]

I will give you the pseudo code:

{ // step #1 do select on both
   select high
   select low
}

if high read:
   return high
else:
   // we read a low so do a high poll
   {
   select high:
   default:
   }

 if high read:
  enqueue low and return high
 else:
  if queue empty:
 return low
  else:
   use queue and enqueue low from step #1 // FIFO order on low reads 

The above code will always return high values over low values (if high 
available), and return low values in order of events


> On Apr 29, 2021, at 8:29 AM, Øyvind Teig  wrote:
> 
> I sent that to the wrong entry! Is it possible that you could make a code 
> example?
> 
> torsdag 29. april 2021 kl. 15:20:40 UTC+2 skrev ren...@ix.netcom.com:
> It is trivial to do a priority select. Check the high priority channel again 
> after getting a low priority value. If the high priority is available enqueue 
> the low value and handle the high. 
> 
> It is also trivial to “delay” the handling to allow more time for high events 
> to arrive if dealing with synchronized events and you need to account for 
> jitter. 
> 
>> On Apr 29, 2021, at 8:10 AM, Øyvind Teig > > wrote:
>> 
>> I agree with you.
> 
>> 
>> However, with the first select in the example we have a "first" and with the 
>> second we have an "after" which might be considered race condition(s9 for 
>> the purpose of seeing the example of what I was after.
>> 
>> Also, scheduling arguments cannot be used here: like "we know that there is 
>> no scheduling (of go goroutines) between the first and the second select." 
>> If we know, it's not an argument.
>> 
>> torsdag 29. april 2021 kl. 14:35:31 UTC+2 skrev axel.wa...@googlemail.com 
>> :
>> On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig > wrote:
>> Interesting! 
>> 
>> Your suggestion would in fact do pri select in the special case 1. below:
>> Poll highPri first (take it if it's ready), if highPri not ready then take 
>> lowPri (provided highPri has not become ready since the first poll)
>> However, if highPri has become ready between the first and the second, then 
>> it would be taken (provided lowPri is not also ready)
>> If both have become ready when the second select is entered they would be 
>> taken 50% of the time on the average
>> 
>> One thing to point out is that since we are talking about concurrency, where 
>> you can really only talk about something happening "after" something else 
>> happened, if there is a causal edge between them, this really *is* 
>> equivalent to a simple priority select. You can't observe the difference, 
>> unless you add more synchronization - in which case we aren't really talking 
>> about the code under discussion anymore.
>> 
>> I fail to see that this is the general pri select that I am quering about 
>> whether it has "appeared" in go over the last years.
>> 
>> I tend to agree with you on this though. So to answer that question plainly: 
>> No, there is no prioritized select in Go and I find it personally unlikely 
>> that we'll get one. It might be possible to address some use cases when we 
>> get generics, though.
>>  
>> I have a stomach feeling that it can not be implemented by polling. In the 
>> semantics of a select the whole select is evaluated before it is entered to 
>> se if there is/are any guard(s) ready. If not, pick randomly. If not, set 
>> alle guards up in some wait state.
>> 
>> The default case I have always used like "since no event ready (polling) 
>> then do something else than listening again on the same events". occam has 
>> deafult (although it's called TRUE & SKIP), xC does not.
>> torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:
>> On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig > 
>> wrote: 
>> 
>> > This is not solved with a default clause, which transforms the selective 
>> > choice waiting for some event to happen into busy polling. It's nice yo 
>> > have some times, but that is something orthogonal to pri/ordered. 
>> 
>> Not sure if I would call it busy polling, but I meant schematically this: 
>> 
>> select { 
>> case x := <-highPriority: 
>> handle(x) 
>> default: 
>> select { 
>> case x := <-highPriority: 
>> handle(x) 
>> case x := <-lowPriority: 
>> handle(x) 
>> } 
>> } 
>> 
>> -- 
>> 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...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/47051a51-f040-4b51-a792-24a0f96c50f4n%40googlegroups.com
>>  
>> .
>> 
>> -- 
>> 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...

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

They could still both have become ready (not in the same "cycle") between 
the two selects. Even if that probability is low, it would need knowledge 
like yours to show that this may in fact be zero. There could be a 
descheduling in between, one of those in my opinion, not relevant arguments.
torsdag 29. april 2021 kl. 15:47:42 UTC+2 skrev Jan Mercl:

> On Thu, Apr 29, 2021 at 3:23 PM Øyvind Teig  wrote:
>
> > 4c is not "correct" as I want it. In the pri select case, if more than 
> one is ready, then they shall not be randomly chosen. Never. They should be 
> selected according to priority.
>
> That's not what 4c says. Instead of "more than one ready" it says
> "both high and low _get ready at the same time_".
>
> Note that in the first approximation the probability of 4c happening
> is approaching zero. If we consider time "ticks" in discrete quanta,
> the probability is proportional to the size of the quantum. And
> depending on a particular implementation of the scheduler the
> probability of 4c can still be exactly zero. For example, the OS
> kernel may deliver only one signal at a time to the process etc.
>
> So the "Never" case may quite well never happen at all.
>

-- 
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/2460a16f-af1b-4613-ba4a-72b13e816a2bn%40googlegroups.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Jan Mercl]

On Thu, Apr 29, 2021 at 3:23 PM Øyvind Teig  wrote:

> 4c is not "correct" as I want it. In the pri select case, if more than one is 
> ready, then they shall not be randomly chosen. Never. They should be selected 
> according to priority.

That's not what 4c says. Instead of "more than one ready" it says
"both high and low _get ready at the same time_".

Note that in the first approximation the probability of 4c happening
is approaching zero. If we consider time "ticks" in discrete quanta,
the probability is proportional to the size of the quantum. And
depending on a particular implementation of the scheduler the
probability of 4c can still be exactly zero. For example, the OS
kernel may deliver only one signal at a time to the process etc.

So the "Never" case may quite well never happen at all.

-- 
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/CAA40n-V6PZwPukSwWfL8QUGW88K7OhaAkSZcoMPj4nLSAPatBw%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

axel, it's difficult to try to explain in words how a select behaves. On 
that we can agree. For me, select cases can be channels, timeouts, external 
events etc. If a task is in a select (none triggered yet) and there is an 
interrupt that detects the select entry, it's ticked as triggered, the 
select is torn down, and in time the select will be taken with that event 
only. Not like Linux select which can deliver several causes. But if the 
timrout came just before the pin, then.. etc. Temporal logic in this case 
certainly makes sense.
torsdag 29. april 2021 kl. 15:28:03 UTC+2 skrev axel.wa...@googlemail.com:

> My argument is that you can't distinguish the case "neither was ready and 
> highPriority and lowPriority became ready simultaneously and lowPriority 
> was selected" from "highPriority became ready after lowPriority" (as long 
> as there is the same code in both highPriority cases). Because there is no 
> "simultaneous" or "after" in concurrency, unless you use synchronization - 
> the real phrasing is "highPriority and lowPriority became ready 
> simultaneously" and if, *in real time* that means one or the other came 
> first is indeterminate. There is no implementation or scheduling argument 
> here - this argument is purely based on the Go memory model and the spec.
>
> If there is no observable difference in behavior, the two are equivalent.
>
> But either way, as I said, it's not really the same, just based on 
> readability and clarity. It's semantically equivalent, but semantically, Go 
> is equivalent to Assembly and yet we prefer Go :)
>
> On Thu, Apr 29, 2021 at 3:11 PM Øyvind Teig  wrote:
>
>> I agree with you.
>>
>> However, with the first select in the example we have a "first" and with 
>> the second we have an "after" which might be considered race condition(s9 
>> for the purpose of seeing the example of what I was after.
>>
>> Also, scheduling arguments cannot be used here: like "we know that there 
>> is no scheduling (of go goroutines) between the first and the second 
>> select." If we know, it's not an argument.
>>
>> torsdag 29. april 2021 kl. 14:35:31 UTC+2 skrev axel.wa...@googlemail.com
>> :
>>
>>> On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig  
>>> wrote:
>>>
 Interesting! 

 Your suggestion would in fact do pri select in the special case 1. 
 below:

1. Poll highPri first (take it if it's ready), if highPri not ready 
then take lowPri (provided highPri has not become ready since the first 
poll)
2. However, if highPri has become ready between the first and the 
second, then it would be taken (provided lowPri is not also ready)
3. If both have become ready when the second select is entered they 
would be taken 50% of the time on the average


>>> One thing to point out is that since we are talking about concurrency, 
>>> where you can really only talk about something happening "after" something 
>>> else happened, if there is a causal edge between them, this really *is* 
>>> equivalent to a simple priority select. You can't observe the difference, 
>>> unless you add more synchronization - in which case we aren't really 
>>> talking about the code under discussion anymore.
>>>
>>> I fail to see that this is the general pri select that I am quering 
 about whether it has "appeared" in go over the last years.

>>>
>>> I tend to agree with you on this though. So to answer that question 
>>> plainly: No, there is no prioritized select in Go and I find it personally 
>>> unlikely that we'll get one. It might be possible to address some use cases 
>>> when we get generics, though.
>>>  
>>>
 I have a stomach feeling that it can not be implemented by polling. In 
 the semantics of a select the whole select is evaluated before it is 
 entered to se if there is/are any guard(s) ready. If not, pick randomly. 
 If 
 not, set alle guards up in some wait state.

 The default case I have always used like "since no event ready 
 (polling) then do something else than listening again on the same events". 
 occam has deafult (although it's called TRUE & SKIP), xC does not.
 torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:

> On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig  
> wrote: 
>
> > This is not solved with a default clause, which transforms the 
> selective choice waiting for some event to happen into busy polling. It's 
> nice yo have some times, but that is something orthogonal to pri/ordered. 
>
> Not sure if I would call it busy polling, but I meant schematically 
> this: 
>
> select { 
> case x := <-highPriority: 
> handle(x) 
> default: 
> select { 
> case x := <-highPriority: 
> handle(x) 
> case x := <-lowPriority: 
> handle(x) 
> } 
> } 
>
 -- 
 You received this message because you are subscribed to the Google 
 Groups "golang-nu

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

I sent that to the wrong entry! Is it possible that you could make a code 
example?

torsdag 29. april 2021 kl. 15:20:40 UTC+2 skrev ren...@ix.netcom.com:

> It is trivial to do a priority select. Check the high priority channel 
> again after getting a low priority value. If the high priority is available 
> enqueue the low value and handle the high. 
>
> It is also trivial to “delay” the handling to allow more time for high 
> events to arrive if dealing with synchronized events and you need to 
> account for jitter. 
>
> On Apr 29, 2021, at 8:10 AM, Øyvind Teig  wrote:
>
> I agree with you.
>
>
> However, with the first select in the example we have a "first" and with 
> the second we have an "after" which might be considered race condition(s9 
> for the purpose of seeing the example of what I was after.
>
> Also, scheduling arguments cannot be used here: like "we know that there 
> is no scheduling (of go goroutines) between the first and the second 
> select." If we know, it's not an argument.
>
> torsdag 29. april 2021 kl. 14:35:31 UTC+2 skrev axel.wa...@googlemail.com:
>
>> On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig  wrote:
>>
>>> Interesting! 
>>>
>>> Your suggestion would in fact do pri select in the special case 1. below:
>>>
>>>1. Poll highPri first (take it if it's ready), if highPri not ready 
>>>then take lowPri (provided highPri has not become ready since the first 
>>>poll)
>>>2. However, if highPri has become ready between the first and the 
>>>second, then it would be taken (provided lowPri is not also ready)
>>>3. If both have become ready when the second select is entered they 
>>>would be taken 50% of the time on the average
>>>
>>>
>> One thing to point out is that since we are talking about concurrency, 
>> where you can really only talk about something happening "after" something 
>> else happened, if there is a causal edge between them, this really *is* 
>> equivalent to a simple priority select. You can't observe the difference, 
>> unless you add more synchronization - in which case we aren't really 
>> talking about the code under discussion anymore.
>>
>> I fail to see that this is the general pri select that I am quering about 
>>> whether it has "appeared" in go over the last years.
>>>
>>
>> I tend to agree with you on this though. So to answer that question 
>> plainly: No, there is no prioritized select in Go and I find it personally 
>> unlikely that we'll get one. It might be possible to address some use cases 
>> when we get generics, though.
>>  
>>
>>> I have a stomach feeling that it can not be implemented by polling. In 
>>> the semantics of a select the whole select is evaluated before it is 
>>> entered to se if there is/are any guard(s) ready. If not, pick randomly. If 
>>> not, set alle guards up in some wait state.
>>>
>>> The default case I have always used like "since no event ready (polling) 
>>> then do something else than listening again on the same events". occam has 
>>> deafult (although it's called TRUE & SKIP), xC does not.
>>> torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:
>>>
 On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig  
 wrote: 

 > This is not solved with a default clause, which transforms the 
 selective choice waiting for some event to happen into busy polling. It's 
 nice yo have some times, but that is something orthogonal to pri/ordered. 

 Not sure if I would call it busy polling, but I meant schematically 
 this: 

 select { 
 case x := <-highPriority: 
 handle(x) 
 default: 
 select { 
 case x := <-highPriority: 
 handle(x) 
 case x := <-lowPriority: 
 handle(x) 
 } 
 } 

>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/47051a51-f040-4b51-a792-24a0f96c50f4n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>> -- 
> 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...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/cf43611c-599f-46d9-98ac-60ede00daea9n%40googlegroups.com
>  
> 
> .
>
>

-- 
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 

Re: [go-nuts] Still "missing" priority or ordered select in go?

['Axel Wagner' via golang-nuts]

My argument is that you can't distinguish the case "neither was ready and
highPriority and lowPriority became ready simultaneously and lowPriority
was selected" from "highPriority became ready after lowPriority" (as long
as there is the same code in both highPriority cases). Because there is no
"simultaneous" or "after" in concurrency, unless you use synchronization -
the real phrasing is "highPriority and lowPriority became ready
simultaneously" and if, *in real time* that means one or the other came
first is indeterminate. There is no implementation or scheduling argument
here - this argument is purely based on the Go memory model and the spec.

If there is no observable difference in behavior, the two are equivalent.

But either way, as I said, it's not really the same, just based on
readability and clarity. It's semantically equivalent, but semantically, Go
is equivalent to Assembly and yet we prefer Go :)

On Thu, Apr 29, 2021 at 3:11 PM Øyvind Teig  wrote:

> I agree with you.
>
> However, with the first select in the example we have a "first" and with
> the second we have an "after" which might be considered race condition(s9
> for the purpose of seeing the example of what I was after.
>
> Also, scheduling arguments cannot be used here: like "we know that there
> is no scheduling (of go goroutines) between the first and the second
> select." If we know, it's not an argument.
>
> torsdag 29. april 2021 kl. 14:35:31 UTC+2 skrev axel.wa...@googlemail.com:
>
>> On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig  wrote:
>>
>>> Interesting!
>>>
>>> Your suggestion would in fact do pri select in the special case 1. below:
>>>
>>>1. Poll highPri first (take it if it's ready), if highPri not ready
>>>then take lowPri (provided highPri has not become ready since the first
>>>poll)
>>>2. However, if highPri has become ready between the first and the
>>>second, then it would be taken (provided lowPri is not also ready)
>>>3. If both have become ready when the second select is entered they
>>>would be taken 50% of the time on the average
>>>
>>>
>> One thing to point out is that since we are talking about concurrency,
>> where you can really only talk about something happening "after" something
>> else happened, if there is a causal edge between them, this really *is*
>> equivalent to a simple priority select. You can't observe the difference,
>> unless you add more synchronization - in which case we aren't really
>> talking about the code under discussion anymore.
>>
>> I fail to see that this is the general pri select that I am quering about
>>> whether it has "appeared" in go over the last years.
>>>
>>
>> I tend to agree with you on this though. So to answer that question
>> plainly: No, there is no prioritized select in Go and I find it personally
>> unlikely that we'll get one. It might be possible to address some use cases
>> when we get generics, though.
>>
>>
>>> I have a stomach feeling that it can not be implemented by polling. In
>>> the semantics of a select the whole select is evaluated before it is
>>> entered to se if there is/are any guard(s) ready. If not, pick randomly. If
>>> not, set alle guards up in some wait state.
>>>
>>> The default case I have always used like "since no event ready (polling)
>>> then do something else than listening again on the same events". occam has
>>> deafult (although it's called TRUE & SKIP), xC does not.
>>> torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:
>>>
 On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig 
 wrote:

 > This is not solved with a default clause, which transforms the
 selective choice waiting for some event to happen into busy polling. It's
 nice yo have some times, but that is something orthogonal to pri/ordered.

 Not sure if I would call it busy polling, but I meant schematically
 this:

 select {
 case x := <-highPriority:
 handle(x)
 default:
 select {
 case x := <-highPriority:
 handle(x)
 case x := <-lowPriority:
 handle(x)
 }
 }

>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/47051a51-f040-4b51-a792-24a0f96c50f4n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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/cf43611c-599f-46d9-98ac-60ede00daea9n%40google

Re: [go-nuts] HTTP request reading

[K. Alex Mills]

Partial responses inline, HTH.

On Thu, Apr 29, 2021, 6:09 AM Amit Saha  wrote:

> Hi all, when an incoming request comes in, does the ListenAndServe()
> function read the first line (as explained in
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages) to figure
> out whether there is a handler registered or not for the path and then
> simply hands it over to the handler (if there is one)?


In the http package, that role is played by the ServeMux
.


> It seems like it is also reading the headers, and then populating the
> http.Request object with them. But, I am curious as to why does it do
> so? Is there any specific header that the server must look for?
>

HTTP headers arrive on the wire before the body, so they have to be
consumed prior to the body. The HTTP package parses them and makes them
available so the handler and middleware can make use of them as needed to
do header-related things like authentication.


> As far as the Body is concerned, that is left to the handler to
> decide, is that correct?
>

I guess you mean that the handler gets to decide for itself whether to read
the body or not. AFAIK, that's correct.

One benefit of parsing the headers into a map is that it makes HTTP
middleware more composeable and easier to write. Parsing the headers first
means different middlewares can examine the same headers. The same is not
true of the body, which can only be consumed once unless you add special
handling to store it in memory for later.


> Thanks,
> Amit.
>
> --
> 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/CANODV3kSLPyV0snkPOr8Q_j%2BR%3DGOfVie2FNxEA1B-8%2BFvQxMEA%40mail.gmail.com
> .
>

-- 
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/CALJzkY8qgh-GKPK_vKC-%3Dz1gGfZoNHT62KfWtMh%3D0bbv-R5afw%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

Jan, I agree on your list, it's better set up than mine. 

But you can add a point after (4.) though, call it (second.pre), dealing 
with what might have happened after the first select decided that none were 
taken until it evaluates the precondition to the second select. 

4c is not "correct" as I want it. In the pri select case, if more than one 
is ready, then they shall not be randomly chosen. Never. They should be 
selected according to priority.

As I discussed (and several with me) in the blog note, the fact that Go 
doesn't seem to have it, then go needs another definition of "fair" than 
what is normal discussing these things. The basic idea for Google was, if 
we have a problem with fairness (none gets starved, all get served), just 
add another computer (said over a beer). Plus, the need for the fairness 
that one can build with a pri select (most often by reordering the list of 
guards according to one's pleasing of what one might think of as fair), is 
according to Goodle (on go, I think), so tiny that we make it simple: drop 
it. Of course it's also easy to try to implement one's own fairness and 
fail with it. In a realtime system it's not that easy to test, and these 
things most often are best evaluated on paper. So a formal proof might do.
torsdag 29. april 2021 kl. 14:58:23 UTC+2 skrev Jan Mercl:

> On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig  wrote:
>
> > Your suggestion would in fact do pri select in the special case 1. below:
> >
> > Poll highPri first (take it if it's ready), if highPri not ready then 
> take lowPri (provided highPri has not become ready since the first poll)
> > However, if highPri has become ready between the first and the second, 
> then it would be taken (provided lowPri is not also ready)
> > If both have become ready when the second select is entered they would 
> be taken 50% of the time on the average
>
> My analysis is different. There are four cases on entry of the outer
> select statement:
>
> 1. high is ready and low is ready -> high handled, correct.
> 2. high is ready and low is not ready -> high handled, correct.
> 3. high is not ready and low is ready -> low handled, correct.
>
> The "interesting" case is
>
> 4. high not ready and low not ready.
>
> We enter the default clause of the outer select statement and enter
> the inner select statement. Now there are three subcases when
> eventually something gets ready:
>
> 4a. high gets ready before low gets ready -> high handled, correct.
> 4b. low gets ready before high gets ready -> low handled, correct.
> 4c. both high and low get ready at the same time -> one of them is
> randomly chosen, correct.
>

-- 
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/3d62317e-4831-47e5-84fe-a932518e48e6n%40googlegroups.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Robert Engels]

It is trivial to do a priority select. Check the high priority channel again 
after getting a low priority value. If the high priority is available enqueue 
the low value and handle the high. 

It is also trivial to “delay” the handling to allow more time for high events 
to arrive if dealing with synchronized events and you need to account for 
jitter. 

> On Apr 29, 2021, at 8:10 AM, Øyvind Teig  wrote:
> 
> I agree with you.
> 
> However, with the first select in the example we have a "first" and with the 
> second we have an "after" which might be considered race condition(s9 for the 
> purpose of seeing the example of what I was after.
> 
> Also, scheduling arguments cannot be used here: like "we know that there is 
> no scheduling (of go goroutines) between the first and the second select." If 
> we know, it's not an argument.
> 
>> torsdag 29. april 2021 kl. 14:35:31 UTC+2 skrev axel.wa...@googlemail.com:
>>> On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig  wrote:
>>> Interesting! 
>>> 
>>> Your suggestion would in fact do pri select in the special case 1. below:
>>> Poll highPri first (take it if it's ready), if highPri not ready then take 
>>> lowPri (provided highPri has not become ready since the first poll)
>>> However, if highPri has become ready between the first and the second, then 
>>> it would be taken (provided lowPri is not also ready)
>>> If both have become ready when the second select is entered they would be 
>>> taken 50% of the time on the average
>> 
>> One thing to point out is that since we are talking about concurrency, where 
>> you can really only talk about something happening "after" something else 
>> happened, if there is a causal edge between them, this really *is* 
>> equivalent to a simple priority select. You can't observe the difference, 
>> unless you add more synchronization - in which case we aren't really talking 
>> about the code under discussion anymore.
>> 
>>> I fail to see that this is the general pri select that I am quering about 
>>> whether it has "appeared" in go over the last years.
>> 
>> I tend to agree with you on this though. So to answer that question plainly: 
>> No, there is no prioritized select in Go and I find it personally unlikely 
>> that we'll get one. It might be possible to address some use cases when we 
>> get generics, though.
>>  
>> 
>>> I have a stomach feeling that it can not be implemented by polling. In the 
>>> semantics of a select the whole select is evaluated before it is entered to 
>>> se if there is/are any guard(s) ready. If not, pick randomly. If not, set 
>>> alle guards up in some wait state.
>>> 
>>> The default case I have always used like "since no event ready (polling) 
>>> then do something else than listening again on the same events". occam has 
>>> deafult (although it's called TRUE & SKIP), xC does not.
> torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:
> On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig  
> wrote: 
> 
> > This is not solved with a default clause, which transforms the 
> > selective choice waiting for some event to happen into busy polling. 
> > It's nice yo have some times, but that is something orthogonal to 
> > pri/ordered. 
> 
> Not sure if I would call it busy polling, but I meant schematically this: 
> 
> select { 
> case x := <-highPriority: 
> handle(x) 
> default: 
> select { 
> case x := <-highPriority: 
> handle(x) 
> case x := <-lowPriority: 
> handle(x) 
> } 
> } 
 
>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/47051a51-f040-4b51-a792-24a0f96c50f4n%40googlegroups.com.
> 
> -- 
> 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/cf43611c-599f-46d9-98ac-60ede00daea9n%40googlegroups.com.

-- 
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/70379213-0E00-4A9C-A183-A59CCFA10467%40ix.netcom.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

I agree with you.

However, with the first select in the example we have a "first" and with 
the second we have an "after" which might be considered race condition(s9 
for the purpose of seeing the example of what I was after.

Also, scheduling arguments cannot be used here: like "we know that there is 
no scheduling (of go goroutines) between the first and the second select." 
If we know, it's not an argument.

torsdag 29. april 2021 kl. 14:35:31 UTC+2 skrev axel.wa...@googlemail.com:

> On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig  wrote:
>
>> Interesting! 
>>
>> Your suggestion would in fact do pri select in the special case 1. below:
>>
>>1. Poll highPri first (take it if it's ready), if highPri not ready 
>>then take lowPri (provided highPri has not become ready since the first 
>>poll)
>>2. However, if highPri has become ready between the first and the 
>>second, then it would be taken (provided lowPri is not also ready)
>>3. If both have become ready when the second select is entered they 
>>would be taken 50% of the time on the average
>>
>>
> One thing to point out is that since we are talking about concurrency, 
> where you can really only talk about something happening "after" something 
> else happened, if there is a causal edge between them, this really *is* 
> equivalent to a simple priority select. You can't observe the difference, 
> unless you add more synchronization - in which case we aren't really 
> talking about the code under discussion anymore.
>
> I fail to see that this is the general pri select that I am quering about 
>> whether it has "appeared" in go over the last years.
>>
>
> I tend to agree with you on this though. So to answer that question 
> plainly: No, there is no prioritized select in Go and I find it personally 
> unlikely that we'll get one. It might be possible to address some use cases 
> when we get generics, though.
>  
>
>> I have a stomach feeling that it can not be implemented by polling. In 
>> the semantics of a select the whole select is evaluated before it is 
>> entered to se if there is/are any guard(s) ready. If not, pick randomly. If 
>> not, set alle guards up in some wait state.
>>
>> The default case I have always used like "since no event ready (polling) 
>> then do something else than listening again on the same events". occam has 
>> deafult (although it's called TRUE & SKIP), xC does not.
>> torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:
>>
>>> On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig  
>>> wrote: 
>>>
>>> > This is not solved with a default clause, which transforms the 
>>> selective choice waiting for some event to happen into busy polling. It's 
>>> nice yo have some times, but that is something orthogonal to pri/ordered. 
>>>
>>> Not sure if I would call it busy polling, but I meant schematically 
>>> this: 
>>>
>>> select { 
>>> case x := <-highPriority: 
>>> handle(x) 
>>> default: 
>>> select { 
>>> case x := <-highPriority: 
>>> handle(x) 
>>> case x := <-lowPriority: 
>>> handle(x) 
>>> } 
>>> } 
>>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/47051a51-f040-4b51-a792-24a0f96c50f4n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/cf43611c-599f-46d9-98ac-60ede00daea9n%40googlegroups.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Jan Mercl]

On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig  wrote:

> Your suggestion would in fact do pri select in the special case 1. below:
>
> Poll highPri first (take it if it's ready), if highPri not ready then take 
> lowPri (provided highPri has not become ready since the first poll)
> However, if highPri has become ready between the first and the second, then 
> it would be taken (provided lowPri is not also ready)
> If both have become ready when the second select is entered they would be 
> taken 50% of the time on the average

My analysis is different. There are four cases on entry of the outer
select statement:

1. high is ready and low is ready -> high handled, correct.
2. high is ready and low is not ready -> high handled, correct.
3. high is not ready and low is ready -> low handled, correct.

The "interesting" case is

4. high not ready and low not ready.

We enter the default clause of the outer select statement and enter
the inner select statement. Now there are three subcases when
eventually something gets ready:

4a. high gets ready before low gets ready -> high handled, correct.
4b. low gets ready before high gets ready -> low handled, correct.
4c. both high and low get ready at the same time -> one of them is
randomly chosen, correct.

-- 
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/CAA40n-X3Mp_Zf2%3DopzuvGSSFSVMr1w_T7rOyGPHeTrVDMm5MAQ%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

['Axel Wagner' via golang-nuts]

On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig  wrote:

> Interesting!
>
> Your suggestion would in fact do pri select in the special case 1. below:
>
>1. Poll highPri first (take it if it's ready), if highPri not ready
>then take lowPri (provided highPri has not become ready since the first
>poll)
>2. However, if highPri has become ready between the first and the
>second, then it would be taken (provided lowPri is not also ready)
>3. If both have become ready when the second select is entered they
>would be taken 50% of the time on the average
>
>
One thing to point out is that since we are talking about concurrency,
where you can really only talk about something happening "after" something
else happened, if there is a causal edge between them, this really *is*
equivalent to a simple priority select. You can't observe the difference,
unless you add more synchronization - in which case we aren't really
talking about the code under discussion anymore.

I fail to see that this is the general pri select that I am quering about
> whether it has "appeared" in go over the last years.
>

I tend to agree with you on this though. So to answer that question
plainly: No, there is no prioritized select in Go and I find it personally
unlikely that we'll get one. It might be possible to address some use cases
when we get generics, though.


> I have a stomach feeling that it can not be implemented by polling. In the
> semantics of a select the whole select is evaluated before it is entered to
> se if there is/are any guard(s) ready. If not, pick randomly. If not, set
> alle guards up in some wait state.
>
> The default case I have always used like "since no event ready (polling)
> then do something else than listening again on the same events". occam has
> deafult (although it's called TRUE & SKIP), xC does not.
> torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:
>
>> On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig 
>> wrote:
>>
>> > This is not solved with a default clause, which transforms the
>> selective choice waiting for some event to happen into busy polling. It's
>> nice yo have some times, but that is something orthogonal to pri/ordered.
>>
>> Not sure if I would call it busy polling, but I meant schematically this:
>>
>> select {
>> case x := <-highPriority:
>> handle(x)
>> default:
>> select {
>> case x := <-highPriority:
>> handle(x)
>> case x := <-lowPriority:
>> handle(x)
>> }
>> }
>>
> --
> 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/47051a51-f040-4b51-a792-24a0f96c50f4n%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfG3QM-TY8Hp3pA6L4%2B%2BX8-zkWqHwgSGuYTBMQnN_EXk8A%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

If not, pick randomly -> If so, pick randomly

torsdag 29. april 2021 kl. 14:26:15 UTC+2 skrev Øyvind Teig:

> Interesting! 
>
> Your suggestion would in fact do pri select in the special case 1. below:
>
>1. Poll highPri first (take it if it's ready), if highPri not ready 
>then take lowPri (provided highPri has not become ready since the first 
>poll)
>2. However, if highPri has become ready between the first and the 
>second, then it would be taken (provided lowPri is not also ready)
>3. If both have become ready when the second select is entered they 
>would be taken 50% of the time on the average
>
> I fail to see that this is the general pri select that I am quering about 
> whether it has "appeared" in go over the last years. I have a stomach 
> feeling that it can not be implemented by polling. In the semantics of a 
> select the whole select is evaluated before it is entered to se if there 
> is/are any guard(s) ready. If not, pick randomly. If not, set alle guards 
> up in some wait state.
>
> The default case I have always used like "since no event ready (polling) 
> then do something else than listening again on the same events". occam has 
> deafult (although it's called TRUE & SKIP), xC does not.
> torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:
>
>> On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig  
>> wrote: 
>>
>> > This is not solved with a default clause, which transforms the 
>> selective choice waiting for some event to happen into busy polling. It's 
>> nice yo have some times, but that is something orthogonal to pri/ordered. 
>>
>> Not sure if I would call it busy polling, but I meant schematically this: 
>>
>> select { 
>> case x := <-highPriority: 
>> handle(x) 
>> default: 
>> select { 
>> case x := <-highPriority: 
>> handle(x) 
>> case x := <-lowPriority: 
>> handle(x) 
>> } 
>> } 
>>
>

-- 
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/7742787e-9c01-4886-80dd-a29b7df861acn%40googlegroups.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

Interesting! 

Your suggestion would in fact do pri select in the special case 1. below:

   1. Poll highPri first (take it if it's ready), if highPri not ready then 
   take lowPri (provided highPri has not become ready since the first poll)
   2. However, if highPri has become ready between the first and the 
   second, then it would be taken (provided lowPri is not also ready)
   3. If both have become ready when the second select is entered they 
   would be taken 50% of the time on the average
   
I fail to see that this is the general pri select that I am quering about 
whether it has "appeared" in go over the last years. I have a stomach 
feeling that it can not be implemented by polling. In the semantics of a 
select the whole select is evaluated before it is entered to se if there 
is/are any guard(s) ready. If not, pick randomly. If not, set alle guards 
up in some wait state.

The default case I have always used like "since no event ready (polling) 
then do something else than listening again on the same events". occam has 
deafult (although it's called TRUE & SKIP), xC does not.
torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:

> On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig  wrote:
>
> > This is not solved with a default clause, which transforms the selective 
> choice waiting for some event to happen into busy polling. It's nice yo 
> have some times, but that is something orthogonal to pri/ordered.
>
> Not sure if I would call it busy polling, but I meant schematically this:
>
> select {
> case x := <-highPriority:
> handle(x)
> default:
> select {
> case x := <-highPriority:
> handle(x)
> case x := <-lowPriority:
> handle(x)
> }
> }
>

-- 
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/47051a51-f040-4b51-a792-24a0f96c50f4n%40googlegroups.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

[Robert Engels]

The point is that if you are timing “so much” that a 1-2 % overhead (so you 
must have tons of very small operations) matter to throughput - sampling will 
still capture enough that a representative event will be recorded.

Still, optimizing time.Now() is always a good idea but I am guessing much of 
the overhead is function call so it will need to be turned into a compiler 
intrinsic (like Java) - I’m also guessing that you are suffering sampling bias 
and even if you fix this you are going to detect a 1-2% overhead somewhere else 
in the path.

You are going to end up using an in memory histogram because the recording of 
the event is going to be more expensive than time.Now() - unless you are going 
to pause the program when an anomaly is detected which is usually not viable. 

1-2% overhead is actually very good for performance monitoring using a general 
purpose OS and GC language like Go. 



> On Apr 29, 2021, at 1:20 AM, Amnon  wrote:
> 
> Why not use the TSC timer for your timings, and convert TSC cycle times into 
> durations during 
> post-run analysis?
> 
>> On Thursday, 29 April 2021 at 04:04:58 UTC+1 Pure White wrote:
>> Hello, 
>> We are doing heavily tracing, and for each func we need to get the time, so 
>> that’s why I’d like to optimize this.
>>> 
> 
> -- 
> 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/e6217b6a-e598-4757-a65f-f89f4d5b7733n%40googlegroups.com.

-- 
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/3EA13551-412B-4355-A93A-ADDE1098C408%40ix.netcom.com.

[go-nuts] HTTP request reading

[Amit Saha]

Hi all, when an incoming request comes in, does the ListenAndServe()
function read the first line (as explained in
https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages) to figure
out whether there is a handler registered or not for the path and then
simply hands it over to the handler (if there is one)?

It seems like it is also reading the headers, and then populating the
http.Request object with them. But, I am curious as to why does it do
so? Is there any specific header that the server must look for?

As far as the Body is concerned, that is left to the handler to
decide, is that correct?

Thanks,
Amit.

-- 
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/CANODV3kSLPyV0snkPOr8Q_j%2BR%3DGOfVie2FNxEA1B-8%2BFvQxMEA%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Jan Mercl]

On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig  wrote:

> This is not solved with a default clause, which transforms the selective 
> choice waiting for some event to happen into busy polling. It's nice yo have 
> some times, but that is something orthogonal to pri/ordered.

Not sure if I would call it busy polling, but I meant schematically this:

select {
case x := <-highPriority:
handle(x)
default:
select {
case x := <-highPriority:
handle(x)
case x := <-lowPriority:
handle(x)
}
}

-- 
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/CAA40n-XD0WkK7ba8ZEsSTEwOhGTL7qNuNnXwyi5VgD-e69OCuw%40mail.gmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

Thanks! A construct like "pri select" or "alt select" or "ordered select", 
so it's not a "wrt", it's a *tagging* of select changing ets sematics from 
being nondeterminstic to deterministic. 

CSP has both: external choice (nondeterminsitic), internal choice 
(deterministic).

The occam programming language has both "ALT" (=select) and "PRI ALT".

The xC programming language has both "select" and "[[ordered]] select".

This is not solved with a default clause, which transforms the selective 
choice waiting for some event to happen into busy polling. It's nice yo 
have some times, but that is something orthogonal to pri/ordered.

torsdag 29. april 2021 kl. 11:15:14 UTC+2 skrev Jan Mercl:

> On Thu, Apr 29, 2021 at 10:52 AM Øyvind Teig  wrote:
>
> > I know from some years ago that go did not have any priority or ordered 
> select construct [1].
>
> Not sure what does "ordered" wrt select mean, but the default clause
> of the select statement provides exactly that - a priority mechanism:
> first try something, otherwise do something else. The most elementary
> one, sure, but all the more complex ones can be built with this basic
> building block.
>

-- 
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/816dc201-9bc8-4d31-ac04-01fa3e73cf3cn%40googlegroups.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Jan Mercl]

On Thu, Apr 29, 2021 at 10:52 AM Øyvind Teig  wrote:

> I know from some years ago that go did not have any priority or ordered 
> select construct [1].

Not sure what does "ordered" wrt select mean, but the default clause
of the select statement provides exactly that - a priority mechanism:
first try something, otherwise do something else. The most elementary
one, sure, but all the more complex ones can be built with this basic
building block.

-- 
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/CAA40n-Xhh2zZSAsvA7e_OSKuT-quCr47iMU0fnbP898K9ZzzCA%40mail.gmail.com.

[go-nuts] Still "missing" priority or ordered select in go?

[Øyvind Teig]

I know from some years ago that go did not have any priority or ordered 
select construct [1].

The idea is that select always is a nondeterministic choice operator, if 
this is still so. Implemented with a random, I assume.

Programming user defined "fair" algorithms or patterns is then not 
possible, I believe.

Is this still so in Go? No prioritised or ordered select in go?

But is there still a way to code this by f.ex. combining several selects? I 
saw a different take at this at [2], where the select is replaced a single 
chan containing a chan bundle, thus becoming "deterministic".

[1] Blog note Nondeterminism 
 
(disclaimer: 
no ads, no gifts, only fun and expenses)

[2] “A pattern for overcoming non-determinism of Golang select statement 

 (3May2019) 
by Pedram Hajesmaeeli

-- 
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/acd2005d-afc7-4cfd-952d-bc2548ea9d41n%40googlegroups.com.

Re: [go-nuts] Re: Multi-word Project Name

[Brian Candler]

Sure.  In the OP's given path "github.com/username/sherlock-server", if it 
provides either "package sherlock" or "package server" it's not too bad.

Thanks for pointing me to goimports.  That does indeed rewrite the example 
as

import (
"fmt"

foo "example.com/my/module/with-a-very-weird-name"
)

-- 
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/a37f3875-e576-4781-a405-fa79fb0b7e98n%40googlegroups.com.

Re: [go-nuts] Re: Multi-word Project Name

['Axel Wagner' via golang-nuts]

Note that goimports theses days adds the package name explicitly to the
import if the package name is not identical to the last component of the
import path. So on the readability front, the cost seem pretty low to me.

It does have a cost on the writing side, as goimports might not find the
package and there's always an extra step to figure out the package name if
you start with the import path (e.g. a GitHub repo).

So yes, I would generally try to avoid it, but it's also not the end of the
world :)

On Thu, Apr 29, 2021, 09:29 Brian Candler  wrote:

> P.S. I don't really recommend this, since you can't tell by inspection of
> main.go which import provides "foo.Greeting".  And I'm struggling to think
> of any real-world examples where I've seen this used.
>
> --
> 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/f6d72692-3638-406a-84c7-75927ce07a1dn%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfGHmeoHCo7uMQKR7v%2BCbauLbJ-bwjLDDw_sZ9xGxi4pnQ%40mail.gmail.com.

Re: [go-nuts] Re: Multi-word Project Name

[Brian Candler]

P.S. I don't really recommend this, since you can't tell by inspection of 
main.go which import provides "foo.Greeting".  And I'm struggling to think 
of any real-world examples where I've seen this used.

-- 
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/f6d72692-3638-406a-84c7-75927ce07a1dn%40googlegroups.com.

Re: [go-nuts] Re: Multi-word Project Name

[Brian Candler]

> Guess by "even if it wasn't" you mean "even if it wasn't top level and 
was exporting functionality"

I think he means in general, you can do this:

// go.mod says "module github.com/my/module/with-a-very-weird-name"
package foo
...

and when you import it, you still get a package "foo".  That's unless you 
rename at import time, e.g.
import (
bar "github.com/my/module/with-a-very-weird-name"
)

Here's a complete example.  To test, cd into pkg1 then do "go mod tidy && 
go run ."  Note that package foo (in directory pkg2) *is* top level and 
*is* exporting functionality.  

==> pkg1/go.mod <==
module example.com/myprog

go 1.16

replace example.com/my/module/with-a-very-weird-name => ../pkg2

require example.com/my/module/with-a-very-weird-name 
v0.0.0-0001010100-

==> pkg1/main.go <==
package main

import (
"example.com/my/module/with-a-very-weird-name"
"fmt"
)

func main() {
fmt.Println(foo.Greeting)
}

==> pkg2/go.mod <==
module example.com/my/module/with-a-very-weird-name

go 1.16

==> pkg2/main.go <==
package foo
var Greeting = "Hello world"

-- 
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/215b42bc-58ee-469e-a2e3-b6970ffaac98n%40googlegroups.com.