|
I'm building a tool that does a lot of computation through lots of goroutines, and pipelining chunks of work in N:M relations. Before I start optimising, I want to know, for each goroutine:
|
#
¿
Jan 17, 2018 18:20
|
|
|
|
| # ¿ May 11, 2024 09:14 |
|
|
@hadlock, I do use go-torch already but, while useful, it's not the right tool for showing the lifecycle of a goroutine @Eela6, those links are extremely my poo poo
|
|
#
¿
Jan 17, 2018 19:39
|
|
|
canis minor posted:I'm beginning with Go, and I can't find a simple, generic way to achieve what I'm after, with people advocating approach no 1 For when you can't be arsed: https://github.com/jmoiron/jsonq
|
|
#
¿
Nov 10, 2018 13:45
|
|
|
Convert it to a number with unsafe.Pointer, or stringise it with fmt.Sprint and compare the strings?
|
|
#
¿
Dec 14, 2018 06:00
|
|
|
Yeah it's safe, eg net.TCPConn.Close -> net.conn.Close -> net.netFD.Close -> internal.poll.FD.Close, which itself wraps each close operation in a call to fd.fdmu.increfAndClose which safely guards against multiple closes of the same FD. You can navigate this stuff fairly easily in just godoc source view mode if you run it with godoc -analysis type -http :7070. strace this example code and you get this output, demonstrating closes on the old socket struct don't impact the newly allocated socket despite it reusing fd 3. I can't speak for your websocket library, but the core library socket impl looks safe.
|
|
#
¿
Feb 5, 2019 00:29
|
|
|
Does building your code with the race detector shed any light?
|
|
#
¿
Feb 20, 2019 05:56
|
|
|
|
| # ¿ May 11, 2024 09:14 |
|
|
Ignoring the "compile struct to parsing code" alternatives, some dynamic stuff: 1. https://github.com/jmoiron/jsonq 2. https://github.com/valyala/fastjson 3. https://github.com/stretchr/objx 4. https://github.com/yalp/jsonpath Ranked in order of interestingness.
|
|
#
¿
Jul 9, 2020 12:06
|
|