*Thanks for this.*
*What it boils down to for me is having a better reasoning for this
suggestion from CodeReviewComments:*
*“The implementing package should return concrete (usually pointer or
struct) types”*
*And that’s the reasoning:*
*“that way, **new methods can be added** to imple
Give lower conccurency a try, like 10 requests per second.
If the counter is still keeping up, never down, there may be a real issue.
Handling http request takes time, it is possible that due to slower action of
Mutex, the system has less concurrent load.
--
You received this message because
This is definitely strange. You're using the atomics correctly.
Are you on a 32-bit platform by any chance? If so, try replacing 64-bit
atomics with 32-bit atomics. The 64-bit atomics should work on 32-bit
platforms, but it wouldn't hurt to test that theory.
If you can extract a standalone te
The file is on memory usually, you might want to save the file on your
drive so you can get the path
--
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+
Go lacks a nice way to hand around a map iteration state. There are
ways to to this, but they either require handing around a doubly-
wrapped closure
```
func iterator(m map[KT]VT) func(func(v VT)) {
return func(fn func (v VT)) {
for _, v := range m {
Thanks, Ian. That makes sense now. It's irritating, but it makes sense.
Relatedly, is there a way to get the output of `go list std` as though
it were a JSON array. It looks to me like this is not possible, at
least, not without all the other information from the documented
struct.
Dan
On Wed, 2
Thanks Jake, that is a good started for me.
On Thursday, August 2, 2018 at 12:12:16 PM UTC-6, Jake Montgomery wrote:
>
> A previous discussion of this was quite long (89 posts) - maybe start
> there:
> https://groups.google.com/d/msg/golang-nuts/ajXzEM6lqJI/wbTPh2TmAwAJ
>
> On Thursday, August
A previous discussion of this was quite long (89 posts) - maybe start
there: https://groups.google.com/d/msg/golang-nuts/ajXzEM6lqJI/wbTPh2TmAwAJ
On Thursday, August 2, 2018 at 1:21:15 PM UTC-4, Andrey Tcherepanov wrote:
>
> The following code does not compile. What was *rationale* behind slices
The following code does not compile. What was *rationale* behind slices
being excluded from being nicely comparable by == like anything else ?
package main
import (
"fmt"
)
func main() {
var a, b []byte
fmt.Println("equals?", a == b)
}
Slices are _excluded_ from deep comparison by stating "Ot
On Thu, Aug 2, 2018 at 9:28 AM, wrote:
> On Wednesday, August 1, 2018 at 10:17:38 AM UTC-4, Ian Lance Taylor wrote:
>>
>> [...]
>> That said, the exact semantics of the sync/atomic operations are not
>> written down (that is https://golang.org/issue/5045).
>
>
> I really love go, but this is one
On Wednesday, August 1, 2018 at 10:17:38 AM UTC-4, Ian Lance Taylor wrote:
>
> [...]
> That said, the exact semantics of the sync/atomic operations are not
> written down (that is https://golang.org/issue/5045).
>
I really love go, but this is one thing that has annoyed me for years. This
issu
I am the author of a Go package which, amongst things, can emit a live
H.264 video stream.
I am looking for a way to display (modified/overlaid) images from the
stream for use in a desktop application which in turn will use my package.
My requirements for a H.264 decoder are:
- reliably ins
When using net/http ProxyFromEnvironment to specify proxy using HTTP_PROXY
environment variable, there is a special case to prevent use of a proxy
when connecting to a localhost or 127.0.0.1 service.
Using a debugging proxy with local services is a common practice, and it
was surprising to fin
Hi everyone!
We are a team of developers who have recently released Containerum platform
written in Go.
There's so much work lying ahead - we are currently working on delivering
convenient revision control, flexible monitoring, etc. And we really need
feedback from the community to know, wh
if h.ServeHTTP(w, r) panic and if is panic is not recovered by the handler
you should alwways do:
atomic.AddInt64(&concur, 1)
defer atomic.AddInt64(&concur, -1)
h.ServeHTTP(w, r)
defer functions always run, even in case of panic
--
You received this message because you are subscribed to the Goog
>
> use defer, in case of panic defer will always run , but probably will be
> slower than mutex
>
>
>
atomic.AddInt64(&concur, 1)
defer atomic.AddInt64(&concur, -1)
h.ServeHTTP(w, r)
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To un
you should use uint64.
and to decremente up 1 use atomic.AddUint64(&concur, ^uint64(0))
--
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...@g
We are having a weird case where an atomic number was increasing and not
decreasing, despite calls to decrease it. Hopefully, someone on the list
can point out something I'm doing wrong with the atomic package.
The function with the issue is:
func UnhealthyOverConcurrent(prefix string, limit in
18 matches
Mail list logo
