ok, accepting that people use libraries with lurking panics, here's my
tweak of Sam Whitted's answer:
*package main*
*func example() {*
* // robust in face of unruly/panic-possible Operation1*
* lockedOperation1 := func() error {*
* lock1.Lock()*
* defer lock1.Unlock()*
* return performOperation1
I guess it depends on what you are logging/doing in response to the interesting
event, and where/when these occur, and how you are detecting them, as the
tracing of the context switch is very cheap.
> On Feb 9, 2019, at 8:10 PM, Milind Chabbi wrote:
>
> Robert,
>
> Tracing is not possible,
Robert,
Tracing is not possible, there will be trillions of instructions logged at
the instruction level tracing.
Let me elaborate a bit more.
The kind of tool I am thinking, intercepts every instruction being executed
on all OS threads in the go process.
The issue is that when an "interesting ev
Milind,
Understood. A few things to think about: 1) the tracing seems pretty efficient
in my tests, although if you don’t want a custom runtime, you’ll need to post
analyze on the file. 2) I think you are going to have a hard time doing what
you are trying to do because of the shared threads, y
Ian,
Can you give me more details about these terms: "g0", "systemstack", and
"mcall"?
Robert: taking the trace route is incorrect for me; I am profiling, tracing
is too expensive because of logging, furthermore, I don't want to recompile
the application or change the go runtime.
-Milind
On Sat
I was referring to this comment (below) made by a different commentor, which
was related to the lock not being released if it panics - and that only matters
if the application doesn’t terminate.
> Recovering from panics is a common and IMO perfectly acceptable practice...
> For example in a web
The original question--the one I answered--was about a small block of user
code and asked nothing about http or unexpected panics.
The spirit of panic/recover, and with defer, includes in its use "local"
panic, a kind of successor to setjump/longjump, that unwinds the stack,
calls defers, and is c
* I have a project 'A' that is importing 'B'
* 'B' uses a vendor folder, if you delete the vendor folder the project
does not compile.
* With `GO111MODULE=on` I am unable to project 'A'. It tries to pull the
latest of 'B', and everything 'B' depends on (instead of using 'B's vendor
folder)
Does
You also need to look at internal/trace to see how the runtime logs the trace
events related to the Go routines - that will show you where you need to
intercept.
> On Feb 9, 2019, at 4:29 PM, robert engels wrote:
>
> It is runtime/trace/trace.go
>
> It is what is reported in the trace facilit
On Sat, Feb 9, 2019 at 2:02 PM wrote:
>
> I am looking at fine-grained calling context collection for go lang programs
> (for all go routines) using binary instrumentation tools such as Intel Pin.
> In a traditional language such as C/C++ intercepting CALL/RET instructions
> (plus some special h
It is runtime/trace/trace.go
It is what is reported in the trace facility. It captures assigning Go routines
to OS thread (processor), and also switching Go routines on a logical processor
(OS thread).
You will still need to use OS level facilities to determine the context
switches of the OS t
I agree, but in that case the ‘panic’ is as you say recognized (and in this
particular case used to unwind from a potentially very deep call), but is then
still returned as an error.
The previous commentor referred to catching “panics" in a top-level http
request processor and continuing to ser
It is slightly more advanced that that - since there are multiple OS threads
that the Go routines are multiplexed onto.
The easiest solution is to look at the ‘trace’ code as it records the context
switches.
> On Feb 9, 2019, at 3:34 PM, milis...@gmail.com wrote:
>
> I am looking at fine-grain
On Fri, Feb 8, 2019 at 7:48 PM Robert Engels wrote:
>
> The way Go is designed a panic must terminate the application. Anything else
> is so indeterminate to be unusable.
I think one can reasonably argue that an unrecognized panic should
terminate the application.
But there is nothing wrong wit
I am looking at fine-grained calling context collection for go lang
programs (for all go routines) using binary instrumentation tools such as
Intel Pin.
In a traditional language such as C/C++ intercepting CALL/RET instructions
(plus some special handling for exceptions setjmp/longjmp) suffices.
As it was already said there are no reasons not to use prefixed tags.
The point was not to restrict prefixless tags and not an opinion *against*
prefixed tags.
These are fine and quite common and good.
Problem is that literally all of my projects and projects of my team use
plain semver tag and
>
> Finally, note that tags like "1.2.3" (without a "v") can still be used,
> but they will not be treated as semantic versions by the 'go' tool.
I think that shouldn't be used as a note or argument since it isn't "usage"
because it cannot be treated as "version" version during version resolu
Oh, and I just realized I linked completely the wrong issue. Here is a good
link: https://golang.org/issues/30116
On Sat, Feb 9, 2019 at 10:31 AM Tyler Compton wrote:
> > A possibly better idea would be to report the line and column number.
> That should uniquely identify which code caused the
> A possibly better idea would be to report the line and column number.
That should uniquely identify which code caused the problem, both for nil
pointer and indexing. The question is how much additional space it would
take to encode column numbers.
I like this idea a lot though I admit that it pr
Other have provided some options. Another option is to use a sentinel value
and check. It is less than ideal for many reasons, but in some cases is
still the best option. In your case it might be to use nil:
var m sync.Mutex
lock := &m
lock.Lock()
defer func() {if lock != nil {lock.Unlock()}}()
i
On Tuesday, February 5, 2019 at 3:03:42 AM UTC-8, ohir wrote:
>
> > Contributors can recreate the same benchmarking routines in C, golang,
> JS
>
> This is how "benchmark game" **entertaining** sites are architectured.
> Their
> "comparisons" are moot for the industry. Look at the history of
On Sunday, February 3, 2019 at 10:44:11 AM UTC-8, Milind Thombre wrote:
>
> … a quantitative performance study/Benchmarking study … If a verifiable
> (unbiased) study is already done and published, I'd greatly appreciate it
> if someone can post the link.
>
What do you not find acceptable abou
YottaDB (https://yottadb.com) is a mature, proven, free / open source
multi-valued key-value NoSQL database. Between YottaDB and the upstream
GT.M (https://sourceforge.net/projects/fis-gtm), the code base currently
runs some of the largest real-time core-banking systems as well as
nation-scale
Btw, before someone gets the wrong impression. You might trap the panic in a
web container, rather than terminating the process, but every request should
just auto respond with a 500 error. You might need the server live to perform
critical error analysis, but even then the best solution is prob
On Fri, Feb 8, 2019 at 7:42 PM Michael Jones wrote:
> clustering:
> https://www.cs.cornell.edu/courses/cs3110/2014fa/lectures/13/lec13.html
>
> careful hash functions often treat short inputs specially.
>
> iterated shift-xor alone is weak in expanding the "changed bits(s)" signal,
> at least by
Hi,
Am new in golang and am trying to write an API but my request header and
body is always empty.
I need help on how to solve this Please.
Thanks in advance.
// Model
type NfInstance struct {
Id bson.ObjectId `json:"nfInstanceID"
bson:"_id,omitempty"` //`json:"nfinstanceI
How about this?
//locking/unlocking mechanism is handled inside performOperation1
if err:= performOperation1(lock1); err!=nil {
return err
}
performExpensiveOperation2()
On Saturday, February 9, 2019 at 1:28:12 AM UTC+7, vincent163 wrote:
>
> I am thinking about how to write programs like th
27 matches
Mail list logo
