he desired ’never
> ends’ state is obtained.
>
> (btw - there are probably some deadlock scenarios - I didn’t spend a lot
> of time on this)
>
>
>
>
>
> On May 12, 2021, at 11:53 AM, Øyvind Teig wrote:
>
> I am not certain whether you start with Java and
I am not certain whether you start with Java and end up with describing a
possible implementation for Go, or stay with Java. In any case Java is your
starting point.
I guess, comparing any feature of any language, from the outside, then the
feature comparison lists turn up. But since you broug
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
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 different
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
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 d
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 inte
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 lower
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 pre
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
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 i
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 qu
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
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 (s
torsdag 6. mai 2021 kl. 04:27:06 UTC+2 skrev tapi...@gmail.com:
> older threads:
> * https://groups.google.com/g/golang-nuts/c/ZrVIhHCrR9o/m/JMJ0fGqhCgAJ
> * https://groups.google.com/g/golang-nuts/c/lEKehHH7kZY/m/gCjjBviJBwAJ
>
Thanks a lot! I'll try to have a look through them!
Øyvind
On T
gt;
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
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
>> https:/
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?
>>>
>
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, yi
t understand why
https://go2goplay.golang.org/p/S_5WFkpqMP_H (By *rog*, 29Apr2021 23:52:05)
seems not to print "Client 2".
Øyvind
>
> On May 3, 2021, at 1:23 PM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>
>
> On Mon, May 3,
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 selec
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 (
>> https://go2go
or granted at all!
Øyvind
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:
>
>> *Axel*, it is impolite not to try to comment and discuss each and every
>> point above.
>
>
> I wasn't trying t
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
bias I will then have to accept that this is Go, nothing more to
say. Just accept it. Anyhow, in case, thank you!
Øyvind
fredag 30. april 2021 kl. 10:42:47 UTC+2 skrev axel.wa...@googlemail.com:
> On Fri, Apr 30, 2021 at 9:53 AM Øyvind Teig wrote:
>
>> If there is no notion of simultanei
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
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 w
orsdag 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 U
I, 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
&g
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
er 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 wi
ity 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 Tei
altime 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
: 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:
>
>&g
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 no
rcl:
> 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/ord
aiting 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
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
possi
Great! I liked Mill's lecture. After having seen it, here's my favourite:
*Clojure core.async*, lecture (45 mins). Rich Hickey discusses the
motivation, design and use of the Clojure core.async library. He also talks
about go. See https://www.infoq.com/presentations/clojure-core-async/
(lecture
Thread safety, concurrency safety, goroutines safety. The same stuff to me.
It's important that concurrent goroutines don't interfere with each other
in such a way that internal state is compromised by other goroutines.
Typically through access to internal data, through pointers. If only go
Thanks for the reference to Dave Cheney's blog note! And for this thread, quite
interesting to read. I am not used to explicitly closing channels at all (occam
(in the ninetees) and XC (now)), but I have sat through several presentations
on conferences seen the theme being discussed, like with t
Hi, Louki Sumirniy
This is not really a response to your problem in particular, so it may totally
miss your target. It's been a while since I did anything in this group.
However, it's a response to the use of buffered channels. It's a coincidence
that I react to your posting (and not the probab
I assume the scope of the discussion about introducing generics is not how
Go-generics might hypothetically be transformed to idiomatic Go. I find no
reference to "unsafe" in neither of these (already mentioned here):
- "Proposal: Go should have generics" by Ian Lance Taylor
https://githu
I assume the scope of the discussion about introducing generics is not how
Go-generics might hypothetically be transformed to idiomatic C. I find no
reference to "unsafe" in neither of these (already mentioned here):
- "Proposal: Go should have generics" by Ian Lance Taylor
https://github
torsdag 30. juni 2016 18.04.13 UTC+2 skrev charr...@gmail.com følgende:
>
>
>
> On Wednesday, June 29, 2016 at 3:42:51 PM UTC+2, Øyvind Teig wrote:
>>
>> The suggestions of generics discussed here and in the referenced
>> documentation, will it be possible to
The suggestions of generics discussed here and in the referenced
documentation, will it be possible to compile the "Go-with-generics"
language into some idiomatic Go and compile it with the standard compiler?
(I guess *what* idiomatic means is the real question here..). Or would it
break idioma
torsdag 16. juni 2016 17.19.58 UTC+2 skrev Øyvind Teig følgende:
>
> occam pi has/had mobile channels, where data pointed to by the pointer
> that's implicitly sent over the channel will fall out of scope on the
> sender side. I don't even think that data is converte
occam pi has/had mobile channels, where data pointed to by the pointer
that's implicitly sent over the channel will fall out of scope in the
sender side. I don't even think that data is converted to a const, the data
won't exist anymore. The language takes care of this.
Sending a pointer across
48 matches
Mail list logo
