[go-nuts] Re: go modules and vendor: redundant features?

Vendoring MUST stay. Athens is another piece of software that has to be set up and keep update. Venoring solves this porblem and ols the one when dependencies go missing. On Saturday, November 17, 2018 at 5:33:55 AM UTC+1, Henry wrote: > > Hi, > > It seems to me that go modules and vendor

Re: [go-nuts] ultra slow os.Exec

The first wait is on read, the 2nd on futex [pid 20441] read(5, "\0\0\0@\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 [pid 20441] rt_sigprocmask(SIG_SETMASK, [HUP INT USR1 USR2 ALRM CHLD IO], NULL, 8) = 0 [pid 20441] rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM

[go-nuts] ultra slow os.Exec

Hey, I'm running windows cli exe on linux via wine using os.Exec command.. this takes 28s to complete. If I run the same command via linux cli it takes 2s to complete, if I run the same command via php's exec it also takes about 2 seconds to complete. == linux cli == time

Re: [go-nuts] ultra slow os.Exec

Robert is right, all 3 examples are the same (they execute the same command with wine being set up and then teared down again). wine itself is not an issue. It's go's exec that does something extremely funny. BR, Miha On Tuesday, November 19, 2019 at 4:22:47 PM UTC+1, Robert Engels wrote: > >

Re: [go-nuts] ultra slow os.Exec

> Doesn't seem to happen with a exec of "/usr/bin/date" so it is most likely something wine+Go specific. Yeah, I did try catting the file and it was fast enough. So you are probably right. Whats interesting is if I do it indirectly via shell script (then this is only 5 times slower not 28):

[go-nuts] cgo memory fragmetation?

Hi guys, We are having a very weird problem, where the process memory keeps rising, but both the pprof and valgrind report no memory leaks. But the RSS just keeps rising.The C part is in external so library To be more exact, the pprof when the process becomes idle reports a few megabytes used

Re: [go-nuts] cgo memory fragmetation?

This doesn't seem to help... gc 589 @171.013s 0%: 0.012+0.69+0.17 ms clock, 0.41+0.079/2.9/1.6+5.5 ms cpu, 6->6->5 MB, 7 MB goal, 32 P scvg: 0 MB released scvg: inuse: 7, idle: 54, sys: 61, released: 54, consumed: 7 (MB) scvg: inuse: 7, idle: 54, sys: 61, released: 54, consumed: 7 (MB) scvg:

Re: [go-nuts] cgo memory fragmetation?

It's not that. The system had 4G of memory initially as it is supposed to be enough for 18 processors (They should max out at around 250M but have the typical of about 100M) and it started swapping heavily. (I then raised the limits to 16G) so things can continue to run. BR, Miha On Monday,

Re: [go-nuts] An important proposal will fail without your support

AFAIK this doesn't work in recent go versions and even less if you are using modules. On Wednesday, March 11, 2020 at 6:39:36 AM UTC+1, Tamás Gulácsi wrote: > > Hi Jon, > > Have you read https://godoc.org/golang.org/x/text/message ? > > It's not gettext, but a better - though not perfect -

Re: [go-nuts] An important proposal will fail without your support

https://github.com/golang/text/pull/9 And I cannot find the issue, but there are a few with extract command not working and crashing. On Wednesday, March 11, 2020 at 9:40:36 AM UTC+1, kortschak wrote: > > Why do you say that? > > ~/src/golang.org/x/text/message [master*]$ go env GO111MODULE >

[go-nuts] Re: Mysterious RSS memory spike

Hey, Vlad, it's not that. we have a similar or rather the exactly the same problem... where the OS doesn't claim the memory back.. this is also annoying to the point we had to disable memory under pressure notifications for that specific host. Also valgrind doesn't report any leaks...

[go-nuts] interface implementing subset not compatible

I'm trying to put external library under the interface but it seems that this is not possible the way I thought it would be... My interfaces are as following... *type Beginner interface {Begin(ctx context.Context) (Tx, error)}type Querier interface {Exec(ctx

[go-nuts] cgo and fatal: morestack on g0

Hey, we are using a library via CGO that is the emulator for a real device. That library also contains a javascript engine which calls to Go for communication to the outside world. The problem we are facing is that we are getting more and more crashes with "morestack on g0". I have found

Re: [go-nuts] Memory usage

And if you are using a cgo and didn't replace the standard malloc with jemaloc you are probably suffering from memory fragmentation or whatever the hell happens. We had to restart the processors every 1000 iterations because of that. There was no memory leak according to valgrind. (about

[go-nuts] Re: Can't read >32KBytes from http response body.

I'm reading a lot of gzipped responses with Go client, so I'd say that this is probably problematic http server and not the client. On Thursday, June 23, 2022 at 2:00:18 AM UTC+2 Kevin Chowski wrote: > Do you have a self-contained reproducer? E.g., a single Go program that > hosts a server