Re: [go-nuts] are Go generics more like C++ or more like Java?

2022-02-28 Thread 'Axel Wagner' via golang-nuts
FYI, a design doc was published , describing the chosen approach for Go 1.18. I thought it might be interesting for people reading/posting to this thread to get an authoritative answer to OP's ques

Re: [go-nuts] Improving on unit test styles

2022-02-28 Thread roger peppe
On Fri, 25 Feb 2022, 18:46 'Markus Zimmermann' via golang-nuts, < golang-nuts@googlegroups.com> wrote: > Hi Gophers! > > We were unhappy with the common unit test styles and we think we found a > style that has clear advantages. An in-depth comparison can be found here > https://symflower.com/en/c

Re: [go-nuts] how cgo handle user define signal ? need go pass the signal handle to c

2022-02-28 Thread Robert Engels
Should be pretty easy to have a Go routine blocked in a C call waiting - then have the signal handler add an event to a memory queue and wake the C thread. Then dispatch to a Go side handler. > On Feb 28, 2022, at 1:49 PM, Ian Lance Taylor wrote: > > On Mon, Feb 28, 2022 at 5:08 AM LordRusk

Re: [go-nuts] how cgo handle user define signal ? need go pass the signal handle to c

2022-02-28 Thread Ian Lance Taylor
On Mon, Feb 28, 2022 at 5:08 AM LordRusk wrote: > > It seems this does not work. Any code ran from a C signal handler must be > async-signal-safe, no go code is async-signal-safe, so it sigfaults when you > try this. https://github.com/golang/go/issues/45499 You can't call Go code directly from t

Re: [go-nuts] support stack size on go linker for musl

2022-02-28 Thread Ian Lance Taylor
On Mon, Feb 28, 2022 at 11:11 AM 'Olaf Flebbe' via golang-nuts wrote: > > I need to call automagically generated C code (matlab models) with cgo on > the musl platform. > > Issue at hand is the code needs quite a bit stack space to run sucessfully. > > It is well known that the default Stack si

[go-nuts] support stack size on go linker for musl

2022-02-28 Thread 'Olaf Flebbe' via golang-nuts
Hi, I need to call automagically generated C code (matlab models) with cgo on the musl platform. Issue at hand is the code needs quite a bit stack space to run sucessfully. It is well known that the default Stack size for threads is quite low for the Musl pplatform (i.e. the alpine distribut

Re: [go-nuts] gollvm build failed

2022-02-28 Thread 'Than McIntosh' via golang-nuts
Hello, Normally the definition of __morestack is drawn from libgcc.a, so I would look to see what the story is with libgcc.a on your system. Here are some things to try: // Ask clang where it's picking up libgcc.a $ clang --print-libgcc-file-name /usr/bin/../lib/gcc/x86_64-linux-gnu/11/libgcc.a

[go-nuts] How long does a goroutine could run successively before being preempted? 10ms or 20ms?

2022-02-28 Thread Hans Allen
Since go1.14, cpu busy goroutine will not occupy a P indefinitely any more. This is done by a cool feature: asynchronously preemption. There is one extra NoP thread(sysmon) runs time to time. It checks if current goroutine has run 10+ms. If so, signal the M runs this goroutine to switch to a

Re: [go-nuts] how cgo handle user define signal ? need go pass the signal handle to c

2022-02-28 Thread LordRusk
It seems this does not work. Any code ran from a C signal handler must be async-signal-safe, no go code is async-signal-safe, so it sigfaults when you try this. https://github.com/golang/go/issues/45499 I really wish there was a way to get around this, there is really no go api for anything to do

Re: [go-nuts] Improving on unit test styles

2022-02-28 Thread 'Dan Kortschak' via golang-nuts
On Fri, 2022-02-25 at 09:26 -0800, 'Markus Zimmermann' via golang-nuts wrote: > Would appreciate your feedback on the style and extension. Would be > also interesting to hear other approaches and conventions that could > help others to write better tests. I'm struggling to understand how you captu

[go-nuts] Re: Improving on unit test styles

2022-02-28 Thread 'Markus Zimmermann' via golang-nuts
First change for github.com/stretchr/testify has been pushed as a PR https://github.com/stretchr/testify/pull/1161: "Include locations of subtests in test failure stack traces". Please give your emoji-support if you agree that this is a good behavior change. More open source changes are coming.