> I haven't verified this, so this is just a guess, but perhaps without
> -trimpath the go tool is using the prebuilt runtime/cgo.a, which was
> built on a system with a C compiler. When you add -trimpath, the
> runtime/cgo package needs to be rebuilt in order to trim the paths.
>
Is there some overhead due to preemption?
About EINTR, I suspect that some programs will have problems.
As an example
https://github.com/golang/go/issues/22838
The issue was reported for MacOS, but technically every signal, including
SIGSTOP, can interrupt a syscall.
Thanks
Manlio
On
And I’ll repeat, you probably need a pool to limit the number of concurrent
processes/connections.
If you had that you would probably of detected the problem sooner.
> On Feb 5, 2020, at 6:32 PM, Robert Engels wrote:
>
>
> I am not familiar with YouTube-dl but if you can pass a timeout on
I am not familiar with YouTube-dl but if you can pass a timeout on the command
line that would be safest.
Using CommandContext will forcibly kill the process.
> On Feb 5, 2020, at 4:13 PM, jnaderl...@gmail.com wrote:
>
>
> So someone answered on the SO question I had posted, explaining how
On Wed, Feb 5, 2020 at 3:40 PM amr wrote:
>
> I'm seeing the same problem, also.
Sorry about that. It's been fixed.
Ian
--
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
I'm seeing the same problem, also.
--
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...@googlegroups.com.
To view this discussion on the web
On Wednesday, February 5, 2020 at 6:12:21 PM UTC-5, Andrey Tcherepanov
wrote:
>
> Sorry to mention, but for me https://tip.golang.org/doc/go1.14 returns
> "template:
> main:846: unexpected EOF"
>
> Not sure if this is because it is work in progress, or too many people
> trying to hit this
Sorry to mention, but for me https://tip.golang.org/doc/go1.14 returns
"template:
main:846: unexpected EOF"
Not sure if this is because it is work in progress, or too many people
trying to hit this site after announcement.
Andrey
On Wednesday, February 5, 2020 at 12:43:47 PM UTC-7, Carlos
On Wed, Feb 5, 2020 at 2:29 PM Liam wrote:
>
> Russ, I apologize for any misunderstanding, but below is the relevant quote
> from your post. When I suggested in response that godoc.org be returned to
> the community, Ian asked if anyone would be interested to take it on. My note
> here was
Russ, I apologize for any misunderstanding, but below is the relevant quote
from your post. When I suggested in response that godoc.org be returned to
the community, Ian asked if anyone would be interested to take it on. My
note here was prompted by Ian's query. (Appended is my post to which
On Wed, Feb 5, 2020 at 2:05 PM Kaveh Shahbazian
wrote:
>>
>> "Goroutines are now asynchronously preemptible."
>
> Very nice!
>
>> "A consequence of the implementation of preemption is that on Unix systems,
>> including Linux and macOS systems, programs built with Go 1.14 will receive
>> more
So someone answered on the SO question I had posted, explaining how to
check the number of processes, they suggest I add a timeout, since it seems
youtube-dl, after succesffully running, sometimes hangs, so it seems golang
isn't closing it sometimes.
Should I do a timeout, orinstead the
>
> "Goroutines are now asynchronously preemptible."
Very nice!
"A consequence of the implementation of preemption is that on Unix systems,
> including Linux and macOS systems, programs built with Go 1.14 will receive
> more signals than programs built with earlier releases. This means that
For threads just use the os command top or ps.
For go routines I would use the net based pprof
> On Feb 5, 2020, at 3:20 PM, jnaderl...@gmail.com wrote:
>
>
> How can I debug the number of threads and go routines running and checking if
> the Wait()'s finish? Because I believe that may be
How can I debug the number of threads and go routines running and checking
if the Wait()'s finish? Because I believe that may be problem, that they
hang.
And when you say append the output, are you saying make a go routine to
write to the headers? If you have an example I would appreciate it
> [go-nuts] Seeking new custodian for godoc.org
The Go team is the custodian for godoc.org and we are not seeking a new one.
> Legal advice will apparently force the Go team to close godoc.org [1]
This is a grotesque misrepresentation of what I wrote. This is what I wrote:
*# Why is there a
Hello gophers,
We have just released go1.14rc1, a release candidate version of Go 1.14.
It is cut from release-branch.go1.14 at the revision tagged go1.14rc1.
Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.
On Wed, Feb 5, 2020 at 9:33 AM Florent Bonneau
wrote:
>
> Using docker image golang:1.13-alpine to build our code :
> - Compiling with "go install -v oursoftware/..." our build is sucessfull
> - Compiling with "go install -v -trimpath oursoftware/..." fails with
> following error :
>
>
> ...
>
>
Using docker image golang:1.13-alpine to build our code :
- Compiling with "go install -v oursoftware/..." our build is *sucessfull*
- Compiling with "go install -v *-trimpath* oursoftware/..." *fails* with
following error :
...
runtime
runtime/cgo
vendor/golang.org/x/crypto/curve25519
#
I think your problem may be
"Depending on the HTTP protocol version and the client, calling
// Write or WriteHeader may prevent future reads on the
// Request.Body. For HTTP/1.x requests, handlers should read any
// needed request body data before writing the response. Once the
On Tue, Feb 4, 2020 at 11:22 PM wrote:
>
> I don't think that is the issue. I have tried it on a few different servers.
> Most recent one with 100 gig's of ram and 50 cores. The load average never
> goes above 9, but the ram slowly but surely on htop starts to go up. The go
> binary ends
Hi,
I have the JSON below in mongodb collection
{
"Id":"3fa85f64-5717-4562-b3fc-2c963f66afa6",
"allowedNssaiList": [
{
"allowedSnssaiList": [
{
"allowedSnssai": {
"sst": 1,
"sd": "2"
},
"IMSI": "2443401",
Background: I was writing an HTTP proxy using net.http which supports both
HTTP/1 and HTTP/2. I need to detect errors and do correct things according
to RFC (https://http2.github.io/http2-spec/#CONNECT).
It turns out that net.http has its own bundled copy of x/net/http2
On Monday, February 3, 2020 at 11:37:08 AM UTC-8, Ian Lance Taylor wrote:
>
> On Mon, Feb 3, 2020 at 8:13 AM Craig Rodrigues > wrote:
> >
> > Regarding the fact that I should not call flag.Parse() from inside an
> init() method in my_test.go file,
> > if a note for this is not added to the
24 matches
Mail list logo
