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 pesudo code into go. Looks like pseudo code for some code generator to me, to implement the pri select. Hmm.. Still, I think you might be misunderstanding the tug between priority and > starvation. > I'd hope not. I know I have been going from one to the other in my attempt at explanations. I usually go this path: if I need fair handling to avoid starvation, start with pri select then implement my own fair algorthm. The priority case with disconnect and alarm is priority only, with no requirement of any fairness. So, yes, those are two different things. However pri select should be *one* thing. > It depends on the frequency and latency of events processing. > If pri select depens on this then it's not the pri select I am thinking on here. That being said, as I said earlier, it's hard to make a test code case to prove things! > There is no structure/language that can address this. > I hope I can prove you wrong with xC. (You are triggering me to show it!) It has determinstic handling with setting up timing requirements: https://www.teigfam.net/oyvind/home/technology/209-my-xc-softblinking-pwm-notes/#timing_analysis Plus, scheduling of multi-logical cores on a cycle basis. There's no opsys below and there is a scheduler in the hw of the xCORE architecture. (No, I have nothing to do with XMOS!) > You either drop or you stall - and often only drop is appropriate for > safety critical systems. > I have related to IEC 61508 (https://en.wikipedia.org/wiki/IEC_61508) in several products over the years. Then how we answered the accreditation controllers was rather important. I'd guess that all of the answers presented here would please them. I hope, also my arguments. Øyvind > On May 5, 2021, at 11:59 AM, Øyvind Teig <oyvin...@teigfam.net> wrote: > > 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 <oyvin...@teigfam.net> 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 >> (and to check that the consuming code was working as intended), the >> producing code deliberately doesn't produce any values on channel 2. >> Instead, it sleeps for a second and produces a "late arrival" message. >> >> It's trivial to take out the if statement and show that it works as you'd >> expect: https://go2goplay.golang.org/p/TjgiOmZtQhR >> > -- > > 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/47600a6c-6783-4cfc-beca-06be2ae48a3dn%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/47600a6c-6783-4cfc-beca-06be2ae48a3dn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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/f1e0ab4b-e229-49b7-a99d-9419168cacb0n%40googlegroups.com.
