If the (sub)step alone is comprehensible just in itself, hiding the previous
(sub)steps and its context, then it is comprehensible when refactored to a
separate function.
An then it is separately testable, documentable, and no collapsing esitor help
is neede when viewing them main function,
Thanks Ian.
I'm using schedtrace and scheddetail to help understand the scheduling
flow, the minimum monitoring window seems to be 1ms only, possible to get
more detailed info?
Furthermore, sched* outputs extensive logs but what I expect, at present,
might be something like when a goroutine is
Hi Ian,
Thank you for the response.Got it.
Basically, fmt.Println(InitStruct) is printing the values of fields, cb and
data, for the struct Foo pointed by InitStruct.
fmt.Printf("%p\n", InitStruct) is printing the memory address.
Btw..can you please clarify the following :
1)Is this the correct
Turns out, other parts of the runtime have decent docs – mgc.go is very
well commented, for example. I may have started my research in the darkest
corners (itab, ptab, ftab, oh my).
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
On Wed, Mar 4, 2020 at 6:44 PM Xiangdong JI wrote:
>
> Given the attached screenshot of pprof output, I wonder how to figure out the
> callers of 'runtime.mcall' and their cost? Thanks.
You can't, but it doesn't matter. The mcall function is used when a
thread changes from executing one
Hi,
Given the attached screenshot of pprof output, I wonder how to figure out
the callers of 'runtime.mcall' and their cost? Thanks.
(The image is generated by profiling BenchmarkGoroutineBlocking).
[image: Capture.JPG]
--
You received this message because you are subscribed to the Google
> What part in particular are you interested in?
I ended up in the runtime code because I'm interested in plugins, the
linker, loader, and how the runtime manages types. In particular, I'm
interested in https://github.com/golang/go/issues/28783. My comment here
explains why:
There are a bunch of talks from Gophercon and elsewhere that cover pieces
of the runtime:
Channels: https://www.youtube.com/watch?v=KBZlN0izeiY
Scheduler: https://www.youtube.com/watch?v=YHRO5WQGh0k
Maps: https://www.youtube.com/watch?v=Tl7mi9QmLns [shameless self plug]
Goroutines, defers,
Thanks for looking into it and simplifying the example!
Just to explain, I added the call to nothing(), because I was worried that
otherwise the result would be recognized as unused and the entire code
would be optimized away. Good to know it's not relevant to reproduce.
Thanks again.
On Wed,
Hi Bryan,
On 4 Mar 2020, at 2:27, 'Bryan C. Mills' via golang-nuts wrote:
Did this work in 1.13?
Actually, no. In 1.13 it triggers the panic as described in this bug:
https://golang.org/issue/35759 is probably related; see especially the
TODO
here
Slightly more minimal, in my testing it seems that the call to 'nothing' is
not needed.
I do not quite know why, but these two lines seem to show how the compiler
is reasoning about this escape:
escape.go:4:11: flow: {heap} = x:
escape.go:4:11: from *y = x (assign) at escape.go:6:5
I do
Folks,
First off thanks for the feedback! -- positive and negative.
Second, hopefully people can trust that I fully understand the standard
approach to code refactoring and writing tests. I have done a bunch of it,
and am sure will continue to do a bunch of it. I understand the merits of
Hi All,
I am trying to debug why a byte slice is escaping in my program. I have a
small reproducible example here:
% cat escape.go
package main
func main() {
x := make([]byte, 5)
y := new([]byte)
*y = x
nothing((*y)[3])
}
func nothing(b byte) {}
% go tool compile -m -m -l escape.go
On Tue, Mar 3, 2020 at 9:15 PM wrote:
>
> Is there any way to learn the internals of the runtime package, besides just
> reading all the code? There are a lot of types in the package with cryptic
> names and no documentation, so if all I have is the code, it's going to be a
> steep learning
You can follow the progress toward 1.14.1
via https://github.com/golang/go/milestone/137
Looking at 1.13.0 and 1.12.0 it looks like the time between a .0 release
and a .0 release is about three weeks. So I'm hoping for a St. Patrick's
Day releases of 1.14.1
Jon
--
You received this message
On Wed, Mar 4, 2020 at 4:09 PM Ian Lance Taylor wrote:
>
> The links that I looked at were speculating about behavior, not
> demonstrating real behavior in kernels. I don't know how to judge
> whether those speculations about hypothetical behavior are correct or
> not. Many things are
On Wed, Mar 4, 2020 at 3:57 AM Nitish Saboo wrote:
>
> I have CGO project.
>
> Following is my C header file and Go code
>
> syslog-node.h
> ===
>
> #ifndef _TEST_H_
> #define _TEST_H_
>
> #include
>
> typedef void (*key_value_cb)(const char* key, const char* value, size_t
>
This is a known problem: https://github.com/golang/go/issues/34993
It was fixed in Go 1.14:
https://go-review.googlesource.com/c/tools/+/202041/
I'm curious what you use hex float for?
On Tuesday, March 3, 2020 at 7:10:00 PM UTC-5, bup...@gmail.com wrote:
> Playground:
On Wed, Mar 4, 2020 at 6:20 AM Philip Boampong wrote:
>
> On Sun, Mar 1, 2020 at 3:55 PM Ian Lance Taylor wrote:
> >
> > If dup2 can 1) close newfd; 2) receive a signal before duping oldfd to
> > newfd; 3) return EINTR leaving newfd closed, then dup2 requires
> > considerable care in any
Thanks for the feedback.
> "If the close operation fails to close fildes2, dup2() shall return -1
> without changing the open file description to which fildes2 refers."
> "If close() is interrupted by a signal that is to be caught, it shall return
> -1 with errno set to [EINTR] and the state of
On Sun, Mar 1, 2020 at 3:55 PM Ian Lance Taylor wrote:
>
> If dup2 can 1) close newfd; 2) receive a signal before duping oldfd to
> newfd; 3) return EINTR leaving newfd closed, then dup2 requires
> considerable care in any multi-threaded program. It requires that if
> one thread is calling dup2,
Now, the qualified selector form is "aPkg.Exported".
The form is the same as object selector, "aObj.Property".
Sometimes, it is not very clear for code readers to recognize
the first parts of such slectors is an import or an object.
So, I think the C++ way "aPkg::Exported" is more readable.
Let's
On Wed, Mar 4, 2020 at 7:24 AM Florin Pățan wrote:
> I think the current solution is a perfectly reasonable solution.
>
> As I explained in the article, you can have 0 performance impact when used
> in production environments, because you can disable this feature.
>
My experience is that a
Hi,
I have CGO project.
Following is my C header file and Go code
syslog-node.h
===
#ifndef _TEST_H_
#define _TEST_H_
#include
typedef void (*key_value_cb)(const char* key, const char* value, size_t
value_len, int work);
typedef struct Foo{
key_value_cb cb;
int data;
On 2020-03-03 22:22, Robert Engels wrote:
> A key statement in the link “ The JIT-generated code is *significantly* faster
> than the ahead-of-time-generated code for small matrix sizes.”
>
> Which is what you were arguing was not possible... you can’t have it both
> ways.
JIT code often
It is not possible to infer the intent of a chunk of code purely from
the expressions. You can see what it does, not what it meant to do.
One way of labeling the intent is to put that code in a function. A
well chosen name can let someone determine what the function was
intended to do, and fix it
On Tue, 3 Mar 2020 at 22:37, Warren Stephens
wrote:
> rog,
>
> Very well said -- but everyone keeps talking about improving the
> maintainability without talking about the "comprehensiblity".
>
> Look at the 2 things below. Which is more quickly comprehensible? We
> cannot conceive of a way to
27 matches
Mail list logo
