I would just copy and paste the stdlib pipe.go and change the ctor to take a
size for the channel. I’m pretty sure that is all that is needed to fix the
problem.
> On Nov 21, 2019, at 11:18 PM, Marcin Romaszewicz wrote:
>
>
> I am in fact replacing an io.Pipe implementation, because I need
I am in fact replacing an io.Pipe implementation, because I need to buffer
some data. io.Pipe doesn't buffer, it just matches up read and writes with
each other.
What I'm effectively doing is producing chunks of data at a certain rate
from one server, and forwarding them to another. Due to the lat
Yes, I already addressed this but I know people often reply as they read.
This is not really a pipe in the traditional posix sense. A bad name, or bad
implementation imo.
> On Nov 21, 2019, at 10:53 PM, Jamil Djadala wrote:
>
> On Thu, 21 Nov 2019 22:37:37 -0600
> Robert Engels wrote:
>
>
On Thu, 21 Nov 2019 22:37:37 -0600
Robert Engels wrote:
> The OP specifically requested io.Reader/Writer interfaces.
>
> A pipe is what he wants. Not a ring buffer. (A pipe essentially has a
> ring buffer in the implementation though).
from https://golang.org/pkg/io/#Pipe :
The data is copie
Not sure why the go pipe doesn’t take a size for the inner channel to make the
synchronous nature optional.
> On Nov 21, 2019, at 10:44 PM, Robert Engels wrote:
>
> Sorry in reading the implementation of a pipe in Go, it may not have the
> desired semantics, especially with a large write buf
Sorry in reading the implementation of a pipe in Go, it may not have the
desired semantics, especially with a large write buffer since writes and reads
are 1 to 1 (very weird impl - this is not a traditional pipe). Dan’s library is
a better choice.
> On Nov 21, 2019, at 10:37 PM, Robert Engels
The package Dan referenced will work too - but it doesn’t look different than
using a pipe with a large write buffer.
> On Nov 21, 2019, at 10:20 PM, Dan Kortschak wrote:
>
> There is this: https://godoc.org/bitbucket.org/ausocean/utils/ring
>
> It has been used in production fairly extensiv
The OP specifically requested io.Reader/Writer interfaces.
A pipe is what he wants. Not a ring buffer. (A pipe essentially has a ring
buffer in the implementation though).
> On Nov 21, 2019, at 10:20 PM, Dan Kortschak wrote:
>
> There is this: https://godoc.org/bitbucket.org/ausocean/utils/
There is this: https://godoc.org/bitbucket.org/ausocean/utils/ring
It has been used in production fairly extensively.
On Thu, 2019-11-21 at 19:47 -0800, Marcin Romaszewicz wrote:
> Hi All,
>
> Before I reinvent the wheel, and because this wheel is particularly
> tricky
> to get right, I was wond
On Thu, Nov 21, 2019 at 7:57 PM Robert Engels wrote:
> Just use a pipe. Part of the std lib.
>
I haven't written any production Go code but am a grey beard. Looking at
the docs, https://golang.org/pkg/io/#Pipe, a io.Pipe provides somewhat
different semantics compared to a traditional ring buffer
Just use a pipe. Part of the std lib.
> On Nov 21, 2019, at 9:47 PM, Marcin Romaszewicz wrote:
>
>
> Hi All,
>
> Before I reinvent the wheel, and because this wheel is particularly tricky to
> get right, I was wondering if anyone was aware of a a library providing
> something like this
>
Hi All,
Before I reinvent the wheel, and because this wheel is particularly tricky
to get right, I was wondering if anyone was aware of a a library providing
something like this
- conforms to io.Reader
- conforms to io.Writer
- Contains a buffer of fixed size, say, 64MB. If you try to write when
You are totally right on that, sorry. It's just > 4k.
On Thu, Nov 21, 2019 at 7:13 PM burak serdar wrote:
> On Thu, Nov 21, 2019 at 4:59 PM Ivan Bertona wrote:
> >
> > 1) Yes if you set NumberOfWorkers high enough (> 4k / num CPUs), and
> your machine is actually capable of handling this worklo
On Thu, Nov 21, 2019 at 4:59 PM Ivan Bertona wrote:
>
> 1) Yes if you set NumberOfWorkers high enough (> 4k / num CPUs), and your
> machine is actually capable of handling this workload. Based on experience
> I'd say you shouldn't expect significant overhead for job scheduling.
Not divided by n
1) Yes if you set NumberOfWorkers high enough (> 4k / num CPUs), and your
machine is actually capable of handling this workload. Based on experience
I'd say you shouldn't expect significant overhead for job scheduling.
2) Not sure this is a question
3) No
4) What you are doing is totally fine at
Agree. Essentially I'm saying the "channel aspect" is not an issue.
On Thu, Nov 21, 2019 at 12:12 PM Robert Engels
wrote:
> He stated "each request takes 2 secs to process" - what's involved in that
> is the important aspect imo.
>
> -Original Message-
> From: Michael Jones
> Sent: Nov 2
He stated "each request takes 2 secs to process" - what's involved in that is the important aspect imo.-Original Message-
From: Michael Jones
Sent: Nov 21, 2019 2:06 PM
To: Robert Engels
Cc: Sankar , golang-nuts
Subject: Re: [go-nuts] golang multiple go routines reading from a channel an
In my (past) benchmarking, I got ~3M channel send/receive operations per
second on my MacBook Pro. It is faster on faster computers. 2k requests/src
is much less than 3M, clearly, and the 1/1000 duty cycle suggests that
you'll have 99.9% non-overhead to do your processing. This is back of the
envel
You need to determine how well they parallelize and what the resource consumption of a request is. For example, if every request can run concurrently at 100% (not possible btw because of switching overhead), and each request takes 0.5 secs of CPU, and 1.5 secs of IO, for a total wall time of 2 secs
On Thu, Nov 21, 2019 at 11:30 AM Sankar wrote:
>
> We have a setup where we have a producer goroutine pumping in a few thousand
> objects into a channel (Approximately 2k requests per second). There are a
> configurable number of goroutines that work as consumers, consuming from this
> single c
We have a setup where we have a producer goroutine pumping in a few
thousand objects into a channel (Approximately 2k requests per second).
There are a configurable number of goroutines that work as consumers,
consuming from this single channel. If none of the consumer threads could
receive the
Yes, I agree. But in some sense, a developer needed to add the 'const', i.e.
decide that the method was immutable as part of the design (and since Go
doesn't have inheritance it is less important). Go doesn't support this through
syntax/compiler it supports it through design philosophy - if th
On Thu, Nov 21, 2019 at 10:39 AM Robert Engels wrote:
>
>
>
> I'm sorry, but isn't the way you enforce immutability is that you don't code
> mutating exported methods? The author controls the package code. Immutability
> is usually only a concern outside the package, and that is clearly supporte
I'm sorry, but isn't the way you enforce immutability is that you don't code
mutating exported methods? The author controls the package code. Immutability
is usually only a concern outside the package, and that is clearly supported.
-Original Message-
>From: burak serdar
>Sent: Nov
On Thu, Nov 21, 2019 at 10:25 AM Robert Engels wrote:
>
> I don't think we are talking about the same thing. You can certainly code an
> immutable object - just don't export any methods that mutate the object, nor
> export ANY fields.
Correct, we're talking about different things. The question
I don't think we are talking about the same thing. You can certainly code an
immutable object - just don't export any methods that mutate the object, nor
export ANY fields.
-Original Message-
>From: burak serdar
>Sent: Nov 21, 2019 11:09 AM
>To: Robert Engels
>Cc: advanderv...@gmail
On Thu, Nov 21, 2019 at 10:05 AM Robert Engels wrote:
>
> To clarify - the author of the package enforces immutability. With Go’s
> design this can be a simple comment on the field. The package shouldn’t be
> that large where this doesn’t work.
The original problem remains: there is no way to e
To clarify - the author of the package enforces immutability. With Go’s design
this can be a simple comment on the field. The package shouldn’t be that large
where this doesn’t work.
> On Nov 21, 2019, at 10:58 AM, Robert Engels wrote:
>
>
> Correct, but if the receiver method is mutating i
Correct, but if the receiver method is mutating it, then it is not an immutable
object.
-Original Message-
>From: burak serdar
>Sent: Nov 21, 2019 10:53 AM
>To: Robert Engels
>Cc: advanderv...@gmail.com, golang-nuts
>Subject: Re: [go-nuts] Enforce immutability through static analy
On Thu, Nov 21, 2019 at 9:49 AM Robert Engels wrote:
>
> They can't unless the instance field is exported. Just hide it via
> encapsulation with accessors.
Can't do that with a receiver. All methods of a type are in the same
package as the type, so all fields are visible to the receiver.
>
> -
They can't unless the instance field is exported. Just hide it via encapsulation with accessors.-Original Message-
From: advanderv...@gmail.com
Sent: Nov 21, 2019 10:15 AM
To: golang-nuts
Subject: [go-nuts] Enforce immutability through static analysis
Dear Gophers!I was wonder if it possi
Hi,
Thanks for posting to the list. A few quick points of order:
On Thu, Nov 21, 2019, at 12:48, Sying wrote:
> Is there anyone how to solve this problem?
Please don't use unnecessary formatting, the large bold text is a bit
off putting. You can speak normally and everyone will hear you, shoutin
Dear Gophers!
I was wonder if it possible to force immutability on the method receiver? I
know Go doesn't support immutable types and that it is possible to pass the
receiver by value but if the receiver struct has a field with a pointer
type the method may still manipulate it:
type Counter st
Because the return of call1 is not nil, you gave it a proper type before
you packed it into the error interface.
see https://golang.org/doc/faq#nil_error for an explanation. This bites
most go programmers at least once.
On Thu, Nov 21, 2019 at 10:33 AM Kevin wrote:
> hi all,
> Im relatively new
hi all,
Im relatively new to go (but been a developer for over 15yrs) and wrote
some code like this and it perplexed me for a couple hours.
```
var _ error = &Error{}
type Error struct{ message string }
func (e *Error) Error() string { return e.message }
func call1() error { return call2() }
func
seems I have found out why you must return a pointer but it has to be of
type `error` return :/
I posted this gotcha a few mins ago.
https://forum.golangbridge.org/t/logic-behind-failing-nil-check/16331?u=kevlar_c
On Wednesday, November 13, 2019 at 5:24:30 PM UTC, Brian Candler wrote:
>
> In http
Is there anyone how to solve this problem?
https://github.com/micro/micro/issues/431
I have try server way, and it still occure the same error.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving ema
37 matches
Mail list logo
