Re: [go-nuts] Trace encoding - traceEv(String/Stack) deferred output always sent at tail of trace file leaving it incomplete until stopped.

2017-01-22 Thread chrisstocktonaz
Hello, On Tuesday, January 3, 2017 at 11:19:12 PM UTC-7, Tarmigan wrote: > > Hi Chris, > > I think that the parsing of the runtime trace information like you are > describing is very interesting. I have been thinking about a similar > continuous tracing and automatic anomaly detection for my a

Re: [go-nuts] Trace encoding - traceEv(String/Stack) deferred output always sent at tail of trace file leaving it incomplete until stopped.

2017-01-22 Thread chrisstocktonaz
Hello, thanks for the response, excuse the late reply here got a bit busy over the holidays. On Wednesday, January 4, 2017 at 2:22:36 AM UTC-7, Dmitry Vyukov wrote: > > Streaming stacks and strings sounds fine to me. I don't see any > potential issues here. > Awesome, I think this alone would

[go-nuts] Re: Thread safety programatic definition for Go

2017-01-01 Thread chrisstocktonaz
On Sunday, January 1, 2017 at 4:43:32 AM UTC-7, josvazg wrote: > > I am trying to come up with a detailed definition of what a thread safe Go > program is (and is not). One that a (go) tool could check by analyzing the > code for me. > > Otherwise: > >- > >A program is globals sa

[go-nuts] Trace encoding - traceEv(String/Stack) deferred output always sent at tail of trace file leaving it incomplete until stopped.

2016-12-31 Thread chrisstocktonaz
Hello, I wrote (rather derived from the stdlib) a reentrant Parser for the Go trace files, so I could stream partial events as they are returned from runtime.ReadTrace(). After learning about the format and reading the go15trace design doc everything makes sense. I've noticed that runtime.trace