[go-nuts] Re: fmt package documentation
Other flags is fixed in Go 1.19: https://pkg.go.dev/fmt@go1.19beta1 Peter On Tuesday, July 5, 2022 at 5:47:55 PM UTC-4 ben...@gmail.com wrote: > At the default URL https://pkg.go.dev/fmt the same thing happens for me > too. However, at https://pkg.go.dev/fmt@master it formats correctly > (pre-formatted block like in the source). So I assume this has been fixed > and the default will be updated soon (when 1.19 comes out?). > > -Ben > > On Tuesday, July 5, 2022 at 12:28:33 PM UTC+12 aetr...@gmail.com wrote: > >> The documentation of the formatting language >> inhttps://cs.opensource.google/go/go/+/master:src/fmt/doc.go;l=132 doesn't >> render the "other flags" section well. It all runs together: >> source: >> Other flags: >>'+'always print a sign for numeric values; >>guarantee ASCII-only output for %q (%+q) >>'-'pad with spaces on the right rather than the left (left-justify >> the field) >>'#'alternate format: add leading 0b for binary (%#b), 0 for octal >> (%#o), >>0x or 0X for hex (%#x or %#X); suppress 0x for %p (%#p); >>for %q, print a raw (backquoted) string if strconv.CanBackquote >>returns true; >>always print a decimal point for %e, %E, %f, %F, %g and %G; >>do not remove trailing zeros for %g and %G; >>write e.g. U+0078 'x' if the character is printable for %U (%#U). >>' '(space) leave a space for elided sign in numbers (% d); >>put spaces between bytes printing strings or slices in hex (% x, % >> X) >>'0'pad with leading zeros rather than spaces; >>for numbers, this moves the padding after the sign; >>ignored for strings, byte slices and byte arrays >> >> rendered- >> Other flags: >> >>- always print a sign for numeric values; guarantee ASCII-only output >>for %q (%+q) >>- pad with spaces on the right rather than the left (left-justify the >>field) # alternate format: add leading 0b for binary (%#b), 0 for octal >>(%#o), 0x or 0X for hex (%#x or %#X); suppress 0x for %p (%#p); for %q, >>print a raw (backquoted) string if strconv.CanBackquote returns true; >>always print a decimal point for %e, %E, %f, %F, %g and %G; do not remove >>trailing zeros for %g and %G; write e.g. U+0078 'x' if the character is >>printable for %U (%#U). ' ' (space) leave a space for elided sign in >>numbers (% d); put spaces between bytes printing strings or slices in hex >>(% x, % X) 0 pad with leading zeros rather than spaces; for numbers, this >>moves the padding after the sign >> >> - >> >> Maybe there's already an issue open for this: it's hard to query for >> src/fmt/doc.go: the terms are too common. >> >> -- Allen >> > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/eafceaaf-ea3f-44f6-8bc9-3c079d6778e6n%40googlegroups.com.
[go-nuts] gopacket get index of IP layer dynamically
Hi Folks, I have a go program that reads some network packets from an interface (not using pcap). Some of packets has 802.1Q encapsulation and some of them has not. I’m searching a way to figure out index of IP layer dynamically from whole packet.(gopacket.Packet.Bytes()) e.g. IP layer starts from 18. byte on packets has 802.1q encapsulation, and 14. bytes for other ones. Is there a clear way to figure out the start index of IP layer? Thanks.. -- Saygılarımla, Hakan SARIMAN -- 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 visit https://groups.google.com/d/msgid/golang-nuts/CANVPHrsfK%2BMK3E-KbG10Mboih4JUF1do%2BjVsBDN1_j%2B9-KSeXQ%40mail.gmail.com.
[go-nuts] Re: fmt package documentation
At the default URL https://pkg.go.dev/fmt the same thing happens for me too. However, at https://pkg.go.dev/fmt@master it formats correctly (pre-formatted block like in the source). So I assume this has been fixed and the default will be updated soon (when 1.19 comes out?). -Ben On Tuesday, July 5, 2022 at 12:28:33 PM UTC+12 aetr...@gmail.com wrote: > The documentation of the formatting language > inhttps://cs.opensource.google/go/go/+/master:src/fmt/doc.go;l=132 doesn't > render the "other flags" section well. It all runs together: > source: > Other flags: >'+'always print a sign for numeric values; >guarantee ASCII-only output for %q (%+q) >'-'pad with spaces on the right rather than the left (left-justify > the field) >'#'alternate format: add leading 0b for binary (%#b), 0 for octal > (%#o), >0x or 0X for hex (%#x or %#X); suppress 0x for %p (%#p); >for %q, print a raw (backquoted) string if strconv.CanBackquote >returns true; >always print a decimal point for %e, %E, %f, %F, %g and %G; >do not remove trailing zeros for %g and %G; >write e.g. U+0078 'x' if the character is printable for %U (%#U). >' '(space) leave a space for elided sign in numbers (% d); >put spaces between bytes printing strings or slices in hex (% x, % > X) >'0'pad with leading zeros rather than spaces; >for numbers, this moves the padding after the sign; >ignored for strings, byte slices and byte arrays > > rendered- > Other flags: > >- always print a sign for numeric values; guarantee ASCII-only output >for %q (%+q) >- pad with spaces on the right rather than the left (left-justify the >field) # alternate format: add leading 0b for binary (%#b), 0 for octal >(%#o), 0x or 0X for hex (%#x or %#X); suppress 0x for %p (%#p); for %q, >print a raw (backquoted) string if strconv.CanBackquote returns true; >always print a decimal point for %e, %E, %f, %F, %g and %G; do not remove >trailing zeros for %g and %G; write e.g. U+0078 'x' if the character is >printable for %U (%#U). ' ' (space) leave a space for elided sign in >numbers (% d); put spaces between bytes printing strings or slices in hex >(% x, % X) 0 pad with leading zeros rather than spaces; for numbers, this >moves the padding after the sign > > - > > Maybe there's already an issue open for this: it's hard to query for > src/fmt/doc.go: the terms are too common. > > -- Allen > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/d0af953d-274b-4140-b0d0-1ec0d86a25e4n%40googlegroups.com.
Re: [go-nuts] Do I need a reentrant locks?
I would put all of the mutations on a queue so they are single threaded. > On Jul 5, 2022, at 9:51 AM, robert engels wrote: > > This is a recipe for bad bugs. Use defensive programming - grab the lock in > the top-level functions, have private functions like ‘doWithLock()’ as a > signal to the developer that they must be holding the lock. > > Allowing callbacks to call back into a concurrent safe structure is very > difficult - because the callbacks can easily be made async as well. > > I would just re-entrant locks. And ensure that no locks are held when the > callback is made - or if it is - it needs to be heavily documented on what > the callee can do. > > Still, in your case without detailing api design available I am guessing you > are going to run in deadlocks very quickly. > > > >> On Jul 5, 2022, at 9:31 AM, Marvin Renich wrote: >> >> * atd...@gmail.com [220705 10:03]: >>> :) That's what the asterisked note was for in the original question. I >>> don't think I can do that in the real code because the real code is much >>> more complex. Each node actually triggers a callback that may modify >>> another node. That callback is user-created, not framework created so I >>> have no way of knowing if the lock has already been taken. >>> >>> And I wouldn't want for library users to have to make that distinction >>> themselves. >> >> Have the Set method always take some type of context, which is a pointer >> type. If the context is nil, assume a top-level call to Set, otherwise >> use the context to decide what to do. All the callbacks will be >> required to accept a context and pass it to the Set method. >> >> If you have multiple goroutines that can be making top-level Set calls, >> I see no way around using something to distinguish top-level calls from >> Set within callbacks. >> >> ...Marvin >> >>> On Tuesday, July 5, 2022 at 3:48:16 PM UTC+2 Brian Candler wrote: >>> Have a public Set() that does the lock and then calls a private internal function, which assumes it's already running under the lock. https://go.dev/play/p/M1XuC8bxCxL On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote: > Hi, > > I have a tree datastructure where mutating some nodes *may *trigger a > mutation on some other tree nodes. > > This tree should be accessible by multiple goroutines but mutated by only > one at a time. > > As such, I wanted to have a global lock on the tree such that mutatiing > node methods should acquire this lock beforehand. > > But it seems to require for the mutex to be reentrant? > > I have tried to create a very simplified*** model to illustrate > https://go.dev/play/p/v37cbYQ1jSY > > (***) I know people might want to suggest for the Set method to use a > lockless variant when iterating over the linked nodes but in the real > code, > it iterates over user created callbacks instead and I don't think I can > expect callbacks writers to juggle between the two kind of methods to > avoid > deadlocks. > > Any suggestion? > > >> >> -- >> 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 visit >> https://groups.google.com/d/msgid/golang-nuts/YsRLSsBPXIbN0Nob%40basil.wdw. > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/957CA77E-9BED-46F6-9C40-4CE17AB7E17B%40ix.netcom.com.
Re: [go-nuts] Do I need a reentrant locks?
This is a recipe for bad bugs. Use defensive programming - grab the lock in the top-level functions, have private functions like ‘doWithLock()’ as a signal to the developer that they must be holding the lock. Allowing callbacks to call back into a concurrent safe structure is very difficult - because the callbacks can easily be made async as well. I would just re-entrant locks. And ensure that no locks are held when the callback is made - or if it is - it needs to be heavily documented on what the callee can do. Still, in your case without detailing api design available I am guessing you are going to run in deadlocks very quickly. > On Jul 5, 2022, at 9:31 AM, Marvin Renich wrote: > > * atd...@gmail.com [220705 10:03]: >> :) That's what the asterisked note was for in the original question. I >> don't think I can do that in the real code because the real code is much >> more complex. Each node actually triggers a callback that may modify >> another node. That callback is user-created, not framework created so I >> have no way of knowing if the lock has already been taken. >> >> And I wouldn't want for library users to have to make that distinction >> themselves. > > Have the Set method always take some type of context, which is a pointer > type. If the context is nil, assume a top-level call to Set, otherwise > use the context to decide what to do. All the callbacks will be > required to accept a context and pass it to the Set method. > > If you have multiple goroutines that can be making top-level Set calls, > I see no way around using something to distinguish top-level calls from > Set within callbacks. > > ...Marvin > >> On Tuesday, July 5, 2022 at 3:48:16 PM UTC+2 Brian Candler wrote: >> >>> Have a public Set() that does the lock and then calls a private internal >>> function, which assumes it's already running under the lock. >>> https://go.dev/play/p/M1XuC8bxCxL >>> >>> On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote: >>> Hi, I have a tree datastructure where mutating some nodes *may *trigger a mutation on some other tree nodes. This tree should be accessible by multiple goroutines but mutated by only one at a time. As such, I wanted to have a global lock on the tree such that mutatiing node methods should acquire this lock beforehand. But it seems to require for the mutex to be reentrant? I have tried to create a very simplified*** model to illustrate https://go.dev/play/p/v37cbYQ1jSY (***) I know people might want to suggest for the Set method to use a lockless variant when iterating over the linked nodes but in the real code, it iterates over user created callbacks instead and I don't think I can expect callbacks writers to juggle between the two kind of methods to avoid deadlocks. Any suggestion? > > -- > 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 visit > https://groups.google.com/d/msgid/golang-nuts/YsRLSsBPXIbN0Nob%40basil.wdw. -- 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 visit https://groups.google.com/d/msgid/golang-nuts/D5D0492E-F34E-4A71-8ACB-157A8DA7F688%40ix.netcom.com.
Re: [go-nuts] Re: Do I need a reentrant locks?
You're absolutely right. (I wrote the simplified example a bit too fast and
missed that in a few places https://go.dev/play/p/9fk_yt0vkHD)
To add the general motivation, I have a reactive UI tree and need to
introduce concurrency (for when async data fetching is done and the data is
reintroduced,, essentially mutating the tree).
On Tuesday, July 5, 2022 at 4:13:01 PM UTC+2 Marvin Renich wrote:
> * Brian Candler [220705 09:48]:
> > Have a public Set() that does the lock and then calls a private internal
> > function, which assumes it's already running under the lock.
> > https://go.dev/play/p/M1XuC8bxCxL
> >
> > On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote:
> >
> > > Hi,
> > >
> > > I have a tree datastructure where mutating some nodes *may *trigger a
> > > mutation on some other tree nodes.
> > >
> > > This tree should be accessible by multiple goroutines but mutated by
> only
> > > one at a time.
> > >
> > > As such, I wanted to have a global lock on the tree such that
> mutatiing
> > > node methods should acquire this lock beforehand.
> > >
> > > But it seems to require for the mutex to be reentrant?
> > >
> > > I have tried to create a very simplified*** model to illustrate
> > > https://go.dev/play/p/v37cbYQ1jSY
> > >
> > > (***) I know people might want to suggest for the Set method to use a
> > > lockless variant when iterating over the linked nodes but in the real
> code,
> > > it iterates over user created callbacks instead and I don't think I
> can
> > > expect callbacks writers to juggle between the two kind of methods to
> avoid
> > > deadlocks.
> > >
> > > Any suggestion?
> > >
> > >
>
> Note also that for referencing a Node to be safe, you must do one of two
> things: either use sync/atomic for all reads and writes of Num
> (assuming the data in the tree is of a type that can be handled by
> sync/atomic), or use sync.RWMutex instead of sync.Mutex, and use RLock
> on reads and Lock on writes.
>
> If Node has more than one data field, e.g. {Name string; Age int; ...},
> you will have to go with the RWMutex option.
>
> ...Marvin
>
>
--
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 visit
https://groups.google.com/d/msgid/golang-nuts/94b3ef70-9431-4a8a-916d-034dd5822d01n%40googlegroups.com.
Re: [go-nuts] Re: Do I need a reentrant locks?
* atd...@gmail.com [220705 10:03]: > :) That's what the asterisked note was for in the original question. I > don't think I can do that in the real code because the real code is much > more complex. Each node actually triggers a callback that may modify > another node. That callback is user-created, not framework created so I > have no way of knowing if the lock has already been taken. > > And I wouldn't want for library users to have to make that distinction > themselves. Have the Set method always take some type of context, which is a pointer type. If the context is nil, assume a top-level call to Set, otherwise use the context to decide what to do. All the callbacks will be required to accept a context and pass it to the Set method. If you have multiple goroutines that can be making top-level Set calls, I see no way around using something to distinguish top-level calls from Set within callbacks. ...Marvin > On Tuesday, July 5, 2022 at 3:48:16 PM UTC+2 Brian Candler wrote: > > > Have a public Set() that does the lock and then calls a private internal > > function, which assumes it's already running under the lock. > > https://go.dev/play/p/M1XuC8bxCxL > > > > On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote: > > > >> Hi, > >> > >> I have a tree datastructure where mutating some nodes *may *trigger a > >> mutation on some other tree nodes. > >> > >> This tree should be accessible by multiple goroutines but mutated by only > >> one at a time. > >> > >> As such, I wanted to have a global lock on the tree such that mutatiing > >> node methods should acquire this lock beforehand. > >> > >> But it seems to require for the mutex to be reentrant? > >> > >> I have tried to create a very simplified*** model to illustrate > >> https://go.dev/play/p/v37cbYQ1jSY > >> > >> (***) I know people might want to suggest for the Set method to use a > >> lockless variant when iterating over the linked nodes but in the real > >> code, > >> it iterates over user created callbacks instead and I don't think I can > >> expect callbacks writers to juggle between the two kind of methods to > >> avoid > >> deadlocks. > >> > >> Any suggestion? > >> > >> -- 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 visit https://groups.google.com/d/msgid/golang-nuts/YsRLSsBPXIbN0Nob%40basil.wdw.
Re: [go-nuts] Re: Do I need a reentrant locks?
* Brian Candler [220705 09:48]:
> Have a public Set() that does the lock and then calls a private internal
> function, which assumes it's already running under the lock.
> https://go.dev/play/p/M1XuC8bxCxL
>
> On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote:
>
> > Hi,
> >
> > I have a tree datastructure where mutating some nodes *may *trigger a
> > mutation on some other tree nodes.
> >
> > This tree should be accessible by multiple goroutines but mutated by only
> > one at a time.
> >
> > As such, I wanted to have a global lock on the tree such that mutatiing
> > node methods should acquire this lock beforehand.
> >
> > But it seems to require for the mutex to be reentrant?
> >
> > I have tried to create a very simplified*** model to illustrate
> > https://go.dev/play/p/v37cbYQ1jSY
> >
> > (***) I know people might want to suggest for the Set method to use a
> > lockless variant when iterating over the linked nodes but in the real code,
> > it iterates over user created callbacks instead and I don't think I can
> > expect callbacks writers to juggle between the two kind of methods to avoid
> > deadlocks.
> >
> > Any suggestion?
> >
> >
Note also that for referencing a Node to be safe, you must do one of two
things: either use sync/atomic for all reads and writes of Num
(assuming the data in the tree is of a type that can be handled by
sync/atomic), or use sync.RWMutex instead of sync.Mutex, and use RLock
on reads and Lock on writes.
If Node has more than one data field, e.g. {Name string; Age int; ...},
you will have to go with the RWMutex option.
...Marvin
--
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 visit
https://groups.google.com/d/msgid/golang-nuts/YsRGy7EdSxvtPoj3%40basil.wdw.
[go-nuts] Re: Do I need a reentrant locks?
:) That's what the asterisked note was for in the original question. I don't think I can do that in the real code because the real code is much more complex. Each node actually triggers a callback that may modify another node. That callback is user-created, not framework created so I have no way of knowing if the lock has already been taken. And I wouldn't want for library users to have to make that distinction themselves. On Tuesday, July 5, 2022 at 3:48:16 PM UTC+2 Brian Candler wrote: > Have a public Set() that does the lock and then calls a private internal > function, which assumes it's already running under the lock. > https://go.dev/play/p/M1XuC8bxCxL > > On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote: > >> Hi, >> >> I have a tree datastructure where mutating some nodes *may *trigger a >> mutation on some other tree nodes. >> >> This tree should be accessible by multiple goroutines but mutated by only >> one at a time. >> >> As such, I wanted to have a global lock on the tree such that mutatiing >> node methods should acquire this lock beforehand. >> >> But it seems to require for the mutex to be reentrant? >> >> I have tried to create a very simplified*** model to illustrate >> https://go.dev/play/p/v37cbYQ1jSY >> >> (***) I know people might want to suggest for the Set method to use a >> lockless variant when iterating over the linked nodes but in the real code, >> it iterates over user created callbacks instead and I don't think I can >> expect callbacks writers to juggle between the two kind of methods to avoid >> deadlocks. >> >> Any suggestion? >> >> -- 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 visit https://groups.google.com/d/msgid/golang-nuts/db0206a8-b113-47ba-9aa5-b3d3680870e2n%40googlegroups.com.
Re: [go-nuts] The program stucked on __vdso_clock_gettime (x86_64)
> > > For me, this looks like the program is merely idling, and what you're > observing is reading current time by the scheduler implemented by the Go > runtime. > I didn't try it. The environment located in customer's data center, not allowed to try this kind of things on it. > > [...] > >1. Any body know the reason of the problem? > > I'm inclined to think that you're merely facing some deadlock or similar > condition which precludes your normal Go code from doing useful progress > while > the runtime itself is OK. > > I agree with this, too. But the program didn't respond to any pprof interaction (We implemented a pprof server using domain socket), so I can not get goroutine information. > >2. What can I do to get more information if this problem happened > again? > > Do the following: > > - Have a way to collect whatever the process is writing to its stderr. > - When the process wedges in the same way, send it SIGQUIT or SIGABRT so > that >it dumps the stacks of all the active goroutines to the stderr and > exits. > > I will try this next time. > If that service handles HTTP requests, you might enable the handlers of the > core debug/pprof package and when the process it apparently wedged > navigate to > its /debug/pprof/goroutine?debug=2 (unless you have grafted the root of > those endpoints somewhere else) to have the stacks sent in the response. > > As I mentioned above, pprof is enabled by default, but the program ceased to respond to anything. Thanks very much. -- 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 visit https://groups.google.com/d/msgid/golang-nuts/CAF_Sdb9imBONz%3DYL4%3DUQ9aqTSwLQT%3DN4eL7_g5AKAEdPsjGrOQ%40mail.gmail.com.
[go-nuts] Re: Do I need a reentrant locks?
Have a public Set() that does the lock and then calls a private internal function, which assumes it's already running under the lock. https://go.dev/play/p/M1XuC8bxCxL On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote: > Hi, > > I have a tree datastructure where mutating some nodes *may *trigger a > mutation on some other tree nodes. > > This tree should be accessible by multiple goroutines but mutated by only > one at a time. > > As such, I wanted to have a global lock on the tree such that mutatiing > node methods should acquire this lock beforehand. > > But it seems to require for the mutex to be reentrant? > > I have tried to create a very simplified*** model to illustrate > https://go.dev/play/p/v37cbYQ1jSY > > (***) I know people might want to suggest for the Set method to use a > lockless variant when iterating over the linked nodes but in the real code, > it iterates over user created callbacks instead and I don't think I can > expect callbacks writers to juggle between the two kind of methods to avoid > deadlocks. > > Any suggestion? > > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/42e71458-8d9c-4b80-9c46-d6d0a96b71abn%40googlegroups.com.
[go-nuts] Do I need a reentrant locks?
Hi, I have a tree datastructure where mutating some nodes *may *trigger a mutation on some other tree nodes. This tree should be accessible by multiple goroutines but mutated by only one at a time. As such, I wanted to have a global lock on the tree such that mutatiing node methods should acquire this lock beforehand. But it seems to require for the mutex to be reentrant? I have tried to create a very simplified*** model to illustrate https://go.dev/play/p/v37cbYQ1jSY (***) I know people might want to suggest for the Set method to use a lockless variant when iterating over the linked nodes but in the real code, it iterates over user created callbacks instead and I don't think I can expect callbacks writers to juggle between the two kind of methods to avoid deadlocks. Any suggestion? -- 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 visit https://groups.google.com/d/msgid/golang-nuts/56e19366-13f0-4be4-aa01-7df7bbf424b3n%40googlegroups.com.
Re: [go-nuts] The program stucked on __vdso_clock_gettime (x86_64)
On Mon, Jul 04, 2022 at 01:57:06AM -0700, Chenhong Liu wrote: [...] > After profiling the process with perf command, the perf data shows the > program looped to call __vdso_clock_gettime . > > 64.20% controllerd [vdso] [.] __vdso_clock_gettime > 8.82% controllerd controllerd [.] runtime.procyield > 8.82% controllerd controllerd [.] runtime.suspendG > 8.01% controllerd controllerd [.] runtime.nanotime1 > 1.47% controllerd [kernel.kallsyms] [k] __enqueue_entity > 0.79% controllerd [kernel.kallsyms] [k] system_call_after_swapgs > 0.79% controllerd [kernel.kallsyms] [k] set_next_entity > 0.68% controllerd [kernel.kallsyms] [k] _raw_gspin_lock > 0.68% controllerd [kernel.kallsyms] [k] change_pte_range > 0.65% controllerd [kernel.kallsyms] [k] auditsys > 0.57% controllerd [kernel.kallsyms] [k] update_curr > 0.45% controllerd [kernel.kallsyms] [k] native_sched_clock > 0.45% controllerd [kernel.kallsyms] [k] cpuacct_charge > 0.45% controllerd [kernel.kallsyms] [k] __x86_indirect_thunk_+rax > 0.45% controllerd [kernel.kallsyms] [k] __audit_syscall_exit > 0.34% controllerd [kernel.kallsyms] [k] pick_next_task_fail > 0.23% controllerd controllerd [.] runtime.osyield > 0.23% controllerd [kernel.kallsyms] [k] native_queuedc_spin_lock_slowpath > 0.23% controllerd [kernel.kallsyms] [k] dput > 0.23% controllerd [kernel.kallsyms] [k] __schedule > 0.23% controllerd [kernel.kallsyms] [k] put_prev_task_fair > 0.23% controllerd [kernel.kallsyms] [k] yield_task_fair > 0.22% controllerd [kernel.kallsyms] [k] sys_sched_yield > 0.11% controllerd [kernel.kallsyms] [k] clear_buddies > 0.11% controllerd [kernel.kallsyms] [k] update_rq_clock.part.78 > 0.11% controllerd [kernel.kallsyms] [k] update_min_vruntime > 0.11% controllerd [kernel.kallsyms] [k] tick_do_update_jiffies64 > 0.11% controllerd [kernel.kallsyms] [k] system_call > 0.11% controllerd [kernel.kallsyms] [k] rb_next > 0.11% controllerd [kernel.kallsyms] [k] rb_insert_color > 0.00% controllerd controllerd [.] runtime.notesleep > 0.00% controllerd [kernel.kallsyms] [k] load_balance > 0.00% controllerd controllerd [.] runtime.runggrab > 0.00% controllerd controllerd [.] runtime.findrunnable > 0.00% controllerd [kernel.kallsyms] [k] update_numa_stats > 0.00% controllerd [kernel.kallsyms] [k] __lock_task_sighand > 0.00% controllerd [kernel.kallsyms] [k] idle_cpu > 0.00% controllerd [kernel.kallsyms] [k] kmem_cache_free_bulk > 0.00% controllerd [kernel.kallsyms] [k] task_numa_find_cpu > 0.00% controllerd [kernel.kallsyms] [k] __queue_work > 0.00% controllerd [kernel.kallsyms] [k] __perf_event_task_sched_in > 0.00% controllerd [kernel.kallsyms] [k] finish_task_switch > 0.00% controllerd [kernel.kallsyms] [k] perf_ctx_unlock > 0.00% controllerd [kernel.kallsyms] [k] native_write_msr_safe > 0.00% controllerd [kernel.kallsyms] [k] __perf_event_enable [...] For me, this looks like the program is merely idling, and what you're observing is reading current time by the scheduler implemented by the Go runtime. [...] >1. Any body know the reason of the problem? I'm inclined to think that you're merely facing some deadlock or similar condition which precludes your normal Go code from doing useful progress while the runtime itself is OK. >2. What can I do to get more information if this problem happened again? Do the following: - Have a way to collect whatever the process is writing to its stderr. - When the process wedges in the same way, send it SIGQUIT or SIGABRT so that it dumps the stacks of all the active goroutines to the stderr and exits. If that service handles HTTP requests, you might enable the handlers of the core debug/pprof package and when the process it apparently wedged navigate to its /debug/pprof/goroutine?debug=2 (unless you have grafted the root of those endpoints somewhere else) to have the stacks sent in the response. -- 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 visit https://groups.google.com/d/msgid/golang-nuts/20220705095534.ay2wdgeinruwuf2w%40carbon.
