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

Robert :) > On May 15, 2021, at 3:48 AM, Øyvind Teig wrote: > > Thanks, rog. I appreciate this! Even if I cant' stop thinking that a "pri" > would have been sligtly more elegant. But you shall be praised for the try! I > wont' take the time to fine read the code, though... > > ..Aside:

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

Thanks, rog. I appreciate this! Even if I cant' stop thinking that a "pri" would have been sligtly more elegant. But you shall be praised for the try! I wont' take the time to fine read the code, though... ..Aside: Being more than busy to digest the fact that XMOS has announced a paradigm

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

Here is a simple priority select implementation using unbuffered channels. https://play.golang.org/p/Hvl0iMr-cFW Uncomment the lines as instructed and you will see that channel A is always picked. What this demonstrates is that ‘priority’ and ‘event

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

lørdag 8. mai 2021 kl. 14:02:37 UTC+2 skrev Ian Lance Taylor: > On Fri, May 7, 2021, 3:10 PM Øyvind Teig wrote: > >> >> fredag 7. mai 2021 kl. 04:10:42 UTC+2 skrev Ian Lance Taylor: >> >>> >>> The reason we don't have such a feature is not because of >>> implementation difficulty. It's because

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

On Fri, May 7, 2021, 3:10 PM Øyvind Teig wrote: > > fredag 7. mai 2021 kl. 04:10:42 UTC+2 skrev Ian Lance Taylor: > >> >> The reason we don't have such a feature is not because of >> implementation difficulty. It's because the feature isn't needed, > > > ..I hope you mean "isn't needed in Go"? >

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

fredag 7. mai 2021 kl. 21:10:39 UTC+2 skrev axel.wa...@googlemail.com: > On Fri, May 7, 2021 at 8:49 PM Øyvind Teig wrote: > >> I don't know if one would use a pri select to pick up channels from the >> same task. Here's a mod that seems to behave wildly differently when the >> channels are

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

fredag 7. mai 2021 kl. 04:10:42 UTC+2 skrev Ian Lance Taylor: > On Thu, May 6, 2021 at 6:40 AM 'Axel Wagner' via golang-nuts > wrote: > > > > FWIW after all this discussion I *am* curious about a more detailed > argument for why we can't have a priority select that guarantees that if > the

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

On Fri, May 7, 2021 at 8:49 PM Øyvind Teig wrote: > I don't know if one would use a pri select to pick up channels from the > same task. Here's a mod that seems to behave wildly differently when the > channels are signalled from one task each and those two tasks are swapped > in order. How may

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

torsdag 6. mai 2021 kl. 22:15:14 UTC+2 skrev axel.wa...@googlemail.com: > To clarify again: As a litmus test, a `select` construct like the one I'm > talking about would mean that this code blocks forever: > https://play.golang.org/p/LcWgDcX5ojl > With the current `select`, it doesn't. With a

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

torsdag 6. mai 2021 kl. 22:08:31 UTC+2 skrev Peter Wilson: > Back in the days of transputers and occam, there was a desire to be able > to manage all interesting events in a system in a within-language (language > being occam) manner. > Interrupts were a problem, because you can't describe

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

torsdag 6. mai 2021 kl. 21:41:11 UTC+2 skrev ren...@ix.netcom.com: > But that is not really true because there are no constraints on if the > source channels are buffered - if they are then my code operates similarly. > > Even if using unbuffered channels there is buffering being done at a

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

torsdag 6. mai 2021 kl. 20:30:59 UTC+2 skrev axel.wa...@googlemail.com: > On Thu, May 6, 2021 at 8:22 PM Robert Engels wrote: > >> “If lo” means that if the lo channel was read. >> > > Exactly. To fulfill the requirements and answering the question, it must > not be read. > > This code will

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

torsdag 6. mai 2021 kl. 16:44:08 UTC+2 skrev rog: > On Thu, 6 May 2021 at 14:41, 'Axel Wagner' via golang-nuts < > golan...@googlegroups.com> wrote: > >> PS: And I'm not saying there is no argument. Maybe "select is not atomic" >> is such an argument. But if there is an argument and/or if this

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

torsdag 6. mai 2021 kl. 16:44:08 UTC+2 skrev rog: > On Thu, 6 May 2021 at 14:41, 'Axel Wagner' via golang-nuts < > golan...@googlegroups.com> wrote: > >> PS: And I'm not saying there is no argument. Maybe "select is not atomic" >> is such an argument. But if there is an argument and/or if this

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

torsdag 6. mai 2021 kl. 16:18:18 UTC+2 skrev axel.wa...@googlemail.com: > On Thu, May 6, 2021 at 4:06 PM Øyvind Teig wrote: > >> If that confirmation really is a confirmation, then the "Mercl code" is >> still not a pri select that matches the pri select I was querying about. >> > > I don't

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

Thank you :) On Fri, May 7, 2021 at 4:10 AM Ian Lance Taylor wrote: > On Thu, May 6, 2021 at 6:40 AM 'Axel Wagner' via golang-nuts > wrote: > > > > FWIW after all this discussion I *am* curious about a more detailed > argument for why we can't have a priority select that guarantees that if >

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

On Thu, May 6, 2021 at 6:40 AM 'Axel Wagner' via golang-nuts wrote: > > FWIW after all this discussion I *am* curious about a more detailed argument > for why we can't have a priority select that guarantees that if the > high-priority case becomes ready before the low-priority one (in the sense

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

To simply this :your request is easily accommodated if all channel state changes and all selects are synchronized. This is easily doable but would crush performance. > On May 6, 2021, at 6:11 PM, Robert Engels wrote: > >  > > >>> On May 6, 2021, at 5:12 PM, 'Axel Wagner' via golang-nuts

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

> On May 6, 2021, at 5:12 PM, 'Axel Wagner' via golang-nuts > wrote: > >  >> On Thu, May 6, 2021 at 11:38 PM Robert Engels wrote: > >> Yes, but barring the nanosecs of a window this is simply implemented as Ian >> wrote with >> >> Select hi >> Default: >>Select hi,lo > > No, it is

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

On Thu, May 6, 2021 at 11:38 PM Robert Engels wrote: > Yes, but barring the nanosecs of a window this is simply implemented as > Ian wrote with > > Select hi > Default: >Select hi,lo > No, it is not. "Barring a nanosecond" is not a guarantee. And that this is not actually doing what I'm

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

Yes, but barring the nanosecs of a window this is simply implemented as Ian wrote with Select hi Default: Select hi,lo If both channels are ready when the code is entered the high will always be taken. There is no such thing as simultaneous source events - even the first that occurred in

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

To clarify again: As a litmus test, a `select` construct like the one I'm talking about would mean that this code blocks forever: https://play.golang.org/p/LcWgDcX5ojl With the current `select`, it doesn't. With a different `select`, which uses source order to express priority and under the

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

Back in the days of transputers and occam, there was a desire to be able to manage all interesting events in a system in a within-language (language being occam) manner. Interrupts were a problem, because you can't describe interrupts as implemented by microprocessors (steal the PC and jump

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

On Thu, May 6, 2021 at 9:40 PM Robert Engels wrote: > But that is not really true because there are no constraints on if the > source channels are buffered - if they are then my code operates similarly. > I was very clear. I was asking if it is possible to implement a priority select with the

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

But that is not really true because there are no constraints on if the source channels are buffered - if they are then my code operates similarly. Even if using unbuffered channels there is buffering being done at a lower level (hardware buffers, network stack buffers, etc) - so not

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

On Thu, May 6, 2021 at 8:22 PM Robert Engels wrote: > “If lo” means that if the lo channel was read. > Exactly. To fulfill the requirements and answering the question, it must not be read. This code will prevent a lo from being processed if a hi is available at > the happens before moment of a

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

“If lo” means that if the lo channel was read. This code will prevent a lo from being processed if a hi is available at the happens before moment of a value being ready. That moment is somewhat arbitrary so it is only mildly different than Select hi: Default: Select hi Select

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

No, it is not. Your "if lo" branch implies that the communication happened - e.g. the sender was already unblocked. A `select` would not unblock the other side unless that's the actual branch taken. On Thu, May 6, 2021 at 7:32 PM Robert Engels wrote: > I already showed you - just change it to >

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

I already showed you - just change it to Select hi Default: Select hi,lo If lo: Select hi Default : Pass And enqueue the lo if a hi and lo are read. That is all that is needed. > On May 6, 2021, at 10:28 AM, 'Axel Wagner' via golang-nuts > wrote: > >  > > >> On

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

On Thu, May 6, 2021 at 4:43 PM roger peppe wrote: > > On Thu, 6 May 2021 at 14:41, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> PS: And I'm not saying there is no argument. Maybe "select is not atomic" >> is such an argument. But if there is an argument and/or if

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

On Thu, 6 May 2021 at 14:41, 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > PS: And I'm not saying there is no argument. Maybe "select is not atomic" > is such an argument. But if there is an argument and/or if this is that > argument, I don't fully understand it myself. >

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

On Thu, May 6, 2021 at 4:06 PM Øyvind Teig wrote: > If that confirmation really is a confirmation, then the "Mercl code" is > still not a pri select that matches the pri select I was querying about. > I don't believe it is. It took a while to wrap my head around it - apologies for that. But

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

Thanks for your comments. I'll try to respond to several here. They also all apply! (Even if I see while I write that two more have arrived.) This thread seems to have taken me to places where I didn't intend to go. Go is no language for this kind of application, not even with a pri select. I

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

PS: And I'm not saying there is no argument. Maybe "select is not atomic" is such an argument. But if there is an argument and/or if this is that argument, I don't fully understand it myself. On Thu, May 6, 2021 at 3:40 PM Axel Wagner wrote: > FWIW after all this discussion I *am* curious about

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

FWIW after all this discussion I *am* curious about a more detailed argument for why we can't have a priority select that guarantees that *if* the high-priority case becomes ready before the low-priority one (in the sense of "there exists a happens-before edge according to the memory model"), the

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

onsdag 5. mai 2021 kl. 22:29:50 UTC+2 skrev Jan Mercl: > On Wed, May 5, 2021 at 6:56 PM Øyvind Teig wrote: > > > hiPri is a disconnect message of a smoke detetector. loPri is a fire > alarm. If the disconnect hiPri is activated before (1 sec to 1 ns) or > simulatenously (same polling of "hw

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

On Wed, May 5, 2021 at 11:34 PM Bakul Shah wrote: > > Imagine that the latency between the device detecting a disconnect > signal and a user hitting a disconnect button is D ns while the fire > detection latency is F ns. So if D > F the device would raise the > alarm even if you implement it all

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

To Ian’s point, you can try to synchronize using an external shared or multiple synced clocks - but the error is too great when comparing cpu frequency events. > On May 5, 2021, at 4:34 PM, Bakul Shah wrote: > > On May 5, 2021, at 9:55 AM, Øyvind Teig wrote: >> >> Here is my cognitive test

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

On May 5, 2021, at 9:55 AM, Øyvind Teig wrote: > > Here is my cognitive test case. It is not 100% realistic, but it's just to > convey my point: > hiPri is a disconnect message of a smoke detetector. loPri is a fire alarm. > If the disconnect hiPri is activated before (1 sec to 1 ns) or

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

On Wed, May 5, 2021 at 9:56 AM Øyvind Teig wrote: > > Here is my cognitive test case. It is not 100% realistic, but it's just to > convey my point: > hiPri is a disconnect message of a smoke detetector. loPri is a fire alarm. > If the disconnect hiPri is activated before (1 sec to 1 ns) or

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

On Wed, May 5, 2021 at 6:56 PM Øyvind Teig wrote: > hiPri is a disconnect message of a smoke detetector. loPri is a fire alarm. > If the disconnect hiPri is activated before (1 sec to 1 ns) or simulatenously > (same polling of "hw pins") as the alarm loPri there should be no alarm being >

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

onsdag 5. mai 2021 kl. 20:53:45 UTC+2 skrev ren...@ix.netcom.com: > You are over complicating things. Start with simple code based on Ian’s. > I guess I am. I guess you mean Ian Davis: https://groups.google.com/g/golang-nuts/c/I9cbvCB86MA/m/zuI0PDc3BgAJ I guess I'd need help to get that

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

You are over complicating things. Start with simple code based on Ian’s. Still, I think you might be misunderstanding the tug between priority and starvation. It depends on the frequency and latency of events processing. There is no structure/language that can address this. You either drop or

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

Thanks, rog! (Blush.. I should have seen it and not nagged about it..) Sorry. Øyvind tirsdag 4. mai 2021 kl. 13:13:51 UTC+2 skrev rog: > On Mon, 3 May 2021 at 20:24, Øyvind Teig wrote: > >> I see that, which is great. But I still don't understand why >>

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

mandag 3. mai 2021 kl. 23:12:03 UTC+2 skrev Øyvind Teig: > mandag 3. mai 2021 kl. 21:44:49 UTC+2 skrev axel.wa...@googlemail.com: > >> On Mon, May 3, 2021 at 9:16 PM Øyvind Teig wrote: >> >>> I don't see where hi and lo are being sent to? >>> >> >> They are being `close`d. Reading from a

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

On Mon, 3 May 2021 at 20:24, Øyvind Teig wrote: > I see that, which is great. But I still don't understand why > https://go2goplay.golang.org/p/S_5WFkpqMP_H (By *rog*, 29Apr2021 > 23:52:05) seems not to print "Client 2". > That's because to try to emphasise the arbitrariness of the producers

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

mandag 3. mai 2021 kl. 21:44:49 UTC+2 skrev axel.wa...@googlemail.com: > On Mon, May 3, 2021 at 9:16 PM Øyvind Teig wrote: > >> I don't see where hi and lo are being sent to? >> > > They are being `close`d. Reading from a closed channel immediately > succeeds, yielding the zero value. > I chose

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

Yes, C for instance. It doesn’t print ‘client 2’ because your code is broken. It prints “late arrival” if you remove the sleep. The main program finishes before the go routine runs. > On May 3, 2021, at 2:24 PM, Øyvind Teig wrote: > >> mandag 3. mai 2021 kl. 21:11:48 UTC+2 skrev

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

On Mon, May 3, 2021 at 9:16 PM Øyvind Teig wrote: > I don't see where hi and lo are being sent to? > They are being `close`d. Reading from a closed channel immediately succeeds, yielding the zero value. I chose to use `close` because it's a non-blocking way to make a channel readable. You could

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

mandag 3. mai 2021 kl. 21:11:48 UTC+2 skrev ren...@ix.netcom.com: > In most “select” implementations a set of “ready” endpoints is returned. > So it is trivial for the reader to prioritize some endpoints over others. > Do you mean in user code in other languages than Go? If so, which ones were

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

mandag 3. mai 2021 kl. 20:23:09 UTC+2 skrev axel.wa...@googlemail.com: > On Mon, May 3, 2021 at 6:34 PM Øyvind Teig wrote: > >> meaning that there is not any state where random select is ever used. >>> It is. >>> >> Trouble A: If random select is never used […] >> > > I was unclear: When I

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

In most “select” implementations a set of “ready” endpoints is returned. So it is trivial for the reader to prioritize some endpoints over others. Because of the way Go select works it is more difficult - requiring nested selects - and it is more easily implemented using multiple readers and

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

On Mon, May 3, 2021 at 6:34 PM Øyvind Teig wrote: > meaning that there is not any state where random select is ever used. >>> >> It is. >> > Trouble A: If random select is never used […] > I was unclear: When I said "It is", I meant "it is used". Your understanding of what select does is

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

søndag 2. mai 2021 kl. 21:42:10 UTC+2 skrev axel.wa...@googlemail.com: > On Sun, May 2, 2021 at 9:23 PM Øyvind Teig wrote: > (Removed clumsy sentence from me. Again: sorry!) Thanks for all this answering, Axel! I have tried to expand on Jan's code ( >>

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

No worries, I was not upset :) But I did misunderstand you, thanks for clearing that up. On Sun, May 2, 2021 at 11:56 PM Øyvind Teig wrote: > Axel, I was saying (at least *meaning*) that it was impolite *of me* not > to answer *your* exhaustive comments! The other way around. But I now see >

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

Axel, I was saying (at least *meaning*) that it was impolite *of me* not to answer *your* exhaustive comments! The other way around. But I now see why you got upset. It may read that way too! I read things over many times, did spell checking, but I didn't see this coming! I will read the rest

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

On Sun, May 2, 2021 at 9:23 PM Øyvind Teig wrote: > *Axel*, it is impolite not to try to comment and discuss each and every > point above. I wasn't trying to be impolite. But I also won't go through your messages sentence by sentence, trying to say something even if I have nothing to say.

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

One more thing, if (by presumably faulty reasoning above) random select is never done, would we need the two guards in the second select? https://go2goplay.golang.org/p/EJ2J1sQXVEk søndag 2. mai 2021 kl. 21:23:13 UTC+2 skrev Øyvind Teig: > *Axel*, it is impolite not to try to comment and

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

*Axel*, it is impolite not to try to comment and discuss each and every point above. I actually started to do exactly that when I discovered that it all boils down to this (FWIW?): I have tried to expand on Jan's code ( https://go2goplay.golang.org/p/7xDzP6Jvyl8), here:

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

On Fri, Apr 30, 2021 at 9:53 AM Øyvind Teig wrote: > If there is no notion of simultaneity why all the effort to describe the > random distribution? > While it's not possible for two cases to become ready at the same time, it's definitely possible for two cases to be ready when entering a

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

fredag 30. april 2021 kl. 02:45:02 UTC+2 skrev 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

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

torsdag 29. april 2021 kl. 23:52:05 UTC+2 skrev rog: > 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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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.

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

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"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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