On Thursday, December 12, 2019 at 3:53:07 PM UTC+1, Bryan C. Mills wrote:
>
> This is a bit off-topic now, but coincidentally we will have another talk
>> (probably by my work colleague) that is related to one of your approaches
>> from the talk:
>>
>> // Glob finds all items with names matching
On Thu, Dec 12, 2019 at 1:17 AM Egon Kocjan wrote:
> My demo is based on a real problem in our code. The issue here is that I
> cannot paste proprietary code and it's large and complex anyway. I
> distilled the problem to a bidi-communication coding exercise. The "go srv"
> in the real code is an
My demo is based on a real problem in our code. The issue here is that I
cannot paste proprietary code and it's large and complex anyway. I
distilled the problem to a bidi-communication coding exercise. The "go srv"
in the real code is an external process with stdin and stdout with a simple
lin
I agree. It seems to me that the problem in example 2 is deep in the
architecture of the program, not just a detail of the `select` statements.
The `connect` function essentially functions as a single-worker “worker
pool”, storing the data in a goroutine (specifically, in the closure of the
`srv
I’m sorry, but it’s very hard to understand when you start with solutions. I
think maybe clearly restating the problem will allow more people to offer up
ideas. To be honest at this point I’m not really certain what you’re trying to
demonstrate or why.
> On Dec 8, 2019, at 12:44 AM, Egon Kocja
I meant lock-free as in "without explicit locks".
The original challenge still stands if someone has a better solution than
me:
"The deadlocks in 2_1.go and 2_2.go are caused by the simplistic and wrong
implementation of bidi-comm, which is what I'll be illustrating. I have
three working soluti
I understand what you are saying but I’ll still suggest that your
premise/design is not correct. There are plenty of useful lock free structures
in Go (see github.com/robaho/go-concurrency-test) but that is not what you are
attempting here... you are using async processing - these are completely
I'll cite myself:
"I'm preparing a short talk about Go channels and select. More
specifically, I want to show what not to do."
and
"it would be tempting to just combine two goroutines into one and handle
caching in a single loop without using locks (I see developers avoid
atomics and locks if th
Probably not. Go is designed for 1:1 and there is no reason to do it
differently. You could probably try to write an async event driven layer (which
it looks like you’ve tried) but why???
It’s like saying I’d really like my plane to float - you can do that -but most
likely you want a boat inste
I'll try to clarify as best as I can, thanks again to anyone looking at
this.
The simple server implementation of "output <- input+1" is here and it is
not "under our control" - it's what we have to work with:
https://github.com/egonk/chandemo/blob/master/server.go
The test runner or client is
I’m sorry but your design is not comprehendible by me, and I’ve done lots of
TCP based services.
i think you only need to emulate classic TCP processing - a reader thread (Go
routine) on each side of the connection using range to read until closed. The
connection is represented by 2 channels -
@Egon,
I'm sure many here would jump in and assist, but you need to help us to
help you by spelling out, specifically and exactly, the problem(s) you want
solved. A few sentences on each challenge should suffice.
--
You received this message because you are subscribed to the Google Groups
"g
Agreed, I see goroutines in general as a big win. But what I intend to talk
about in the presentation:
- we have two unidirectional flows of data resembling something like a TCP
socket, easy to do with two goroutines with a for loop
- let's add caching, so some requests do not go to the server
-
To clarify, with Go’s very lightweight threads it is “doing the multiplexing
for you” - often only a single CPU is consumed if the producer and consumer
work cannot be parallelized, otherwise you get this concurrency “for free”.
You are trying to manually perform the multiplexing - you need asyn
A channel is much closer to a pipe. There are producers and consumers and these
are typically different threads of execution unless you have an event based
(async) system - that is not Go.
> On Dec 6, 2019, at 9:30 AM, Egon Kocjan wrote:
>
>
> There are goroutines in the examples of course,
There are goroutines in the examples of course, just a single goroutine per
bidi channel seems hard. By contrast, I've worked with actor systems before
and they are perfectly fine with a single fiber.
On Friday, December 6, 2019 at 3:38:20 PM UTC+1, Robert Engels wrote:
>
> Channels are designed
Channels are designed to be used with multiple go routines - if you’re not you
are doing something wrong.
> On Dec 6, 2019, at 8:32 AM, Egon Kocjan wrote:
>
>
> Hello
>
> I'm preparing a short talk about Go channels and select. More specifically, I
> want to show what not to do. I chose a
17 matches
Mail list logo
