Re: [go-nuts] cgo wrapper function not working in buildmode=c-shared with exported function

2019-12-05 Thread Dan Kortschak 
Thanks, Ian and Andrey.

On Thu, 2019-12-05 at 21:06 -0800, Ian Lance Taylor wrote:
> On Thu, Dec 5, 2019 at 9:02 PM andrey mirtchovski <
> mirtchov...@gmail.com> wrote:
> > 
> > i think cgo does some magic with defining functions called via
> > C.funcname. if you have the same func defined in the C preamble as
> > well as call it from the same Go file you get the same func defined
> > twice. putting it elsewhere as an extern seems to work.
> > 
> > to be honest i never dug into it. i did it once for callbacks in a
> > library in 2013 and forgot about it :) it just works.
> 
> That is basically right.
> 
> This is documented at 
> https://golang.org/cmd/cgo/#hdr-C_references_to_Go:
> 
> Using //export in a file places a restriction on the preamble: since
> it is copied into two different C output files, it must not contain
> any definitions, only declarations. If a file contains both
> definitions and declarations, then the two output files will produce
> duplicate symbols and the linker will fail. To avoid this,
> definitions
> must be placed in preambles in other files, or in C source files.
> 
> Ian
> 
> 
> > On Thu, Dec 5, 2019 at 9:52 PM Dan Kortschak 
> > wrote:
> > > 
> > > Thanks. Can you explain the reason for this so it sticks in my
> > > head?
> > > 
> > > On Thu, 2019-12-05 at 21:03 -0700, andrey mirtchovski wrote:
> > > > you just need to split it in two files. the cfuncs go into
> > > > another
> > > > (sorry for lack of playground link):
> > > > 
> > > > $ go build cgo.go cfunc.go
> > > > $ ./cgo
> > > > Hello from stdio
> > > > 
> > > > $ cat cgo.go
> > > > package main
> > > > 
> > > > /*
> > > > #include 
> > > > extern void myprint(char *s);
> > > > */
> > > > import "C"
> > > > 
> > > > import "unsafe"
> > > > 
> > > > //export Example
> > > > func Example() {
> > > > cs := C.CString("Hello from stdio\n")
> > > > C.myprint(cs)
> > > > C.free(unsafe.Pointer(cs))
> > > > }
> > > > 
> > > > func main() {
> > > > Example()
> > > > }
> > > > $ cat cfunc.go
> > > > package main
> > > > 
> > > > /*
> > > > #include 
> > > > #include 
> > > > 
> > > > void myprint(char* s) {
> > > > printf("%s\n", s);
> > > > }
> > > > */
> > > > import "C"
> > > > 
> > > > On Thu, Dec 5, 2019 at 8:47 PM Dan Kortschak 
> > > > wrote:
> > > > > 
> > > > > I am trying to write a shared module that will be called from
> > > > > C,
> > > > > but I
> > > > > have run into a problem in using the work-around in
> > > > > https://github.com/golang/go/wiki/cgo#the-basics for calling
> > > > > variadic C
> > > > > functions.
> > > > > 
> > > > > The case that I have is more complex, but altering the
> > > > > example at
> > > > > the
> > > > > wiki demonstrates the problem; the function definition that
> > > > > is used
> > > > > to
> > > > > call on to printf appears more than once in the C code
> > > > > generated by
> > > > > Cgo.
> > > > > 
> > > > > ```
> > > > > ~/src/github.com/kortschak/cgo $ cat cgo.go
> > > > > package main
> > > > > 
> > > > > /*
> > > > > #include 
> > > > > #include 
> > > > > 
> > > > > void myprint(char* s) {
> > > > > printf("%s\n", s);
> > > > > }
> > > > > */
> > > > > import "C"
> > > > > 
> > > > > import "unsafe"
> > > > > 
> > > > > //export Example
> > > > > func Example() {
> > > > > cs := C.CString("Hello from stdio\n")
> > > > > C.myprint(cs)
> > > > > C.free(unsafe.Pointer(cs))
> > > > > }
> > > > > 
> > > > > func main() {}
> > > > > ~/src/github.com/kortschak/cgo $ go build -o cgo.so
> > > > > -buildmode=c-
> > > > > shared
> > > > > .
> > > > > # github.com/kortschak/cgo
> > > > > /tmp/go-build899365101/b001/_x002.o: In function `printf':
> > > > > /usr/include/x86_64-linux-gnu/bits/stdio2.h:104: multiple
> > > > > definition of
> > > > > `myprint'
> > > > > /tmp/go-build899365101/b001/_x001.o:/usr/include/x86_64-
> > > > > linux-
> > > > > gnu/bits/stdio2.h:104: first defined here
> > > > > collect2: error: ld returned 1 exit status
> > > > > ```
> > > > > 
> > > > > Removing the "//export Example" comment prevents this
> > > > > failure, but
> > > > > then
> > > > > obviously also loses the exported function. I have tried
> > > > > protecting
> > > > > the
> > > > > function in a #ifndef/#endif, to no avail.
> > > > > 
> > > > > Is it reasonable for me to expect this to work? If so, what
> > > > > am I
> > > > > doing
> > > > > wrong?
> > > > > 
> > > > > thanks
> > > > > Dan
> > > > > 
> > > > > --
> > > > > 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/ab825669afe753c505952f18fb6c61bc8e2dd24d.camel%40kortschak.io
> > > > > .
> > 
> > --
> > You received this message because you are subscribed to the

Re: [go-nuts] Multiple processes in parallel for cgo service

2019-12-05 Thread Ian Lance Taylor 
On Thu, Dec 5, 2019 at 2:41 AM Nitish Saboo  wrote:
>
> I am having a cgo(go + c) service.Is it possible to run multiple processes of 
> the same service in parallel ?

Well, it depends on what the service does.  But there is nothing in
the Go tools or standard library that prevents you from doing this.

Ian

-- 
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/CAOyqgcWYW0UGqs-2Xut7En-7otjf6uN9exJdsyAWQU1ua5itUQ%40mail.gmail.com.

Re: [go-nuts] cgo wrapper function not working in buildmode=c-shared with exported function

2019-12-05 Thread Ian Lance Taylor 
On Thu, Dec 5, 2019 at 9:02 PM andrey mirtchovski  wrote:
>
> i think cgo does some magic with defining functions called via
> C.funcname. if you have the same func defined in the C preamble as
> well as call it from the same Go file you get the same func defined
> twice. putting it elsewhere as an extern seems to work.
>
> to be honest i never dug into it. i did it once for callbacks in a
> library in 2013 and forgot about it :) it just works.

That is basically right.

This is documented at https://golang.org/cmd/cgo/#hdr-C_references_to_Go:

Using //export in a file places a restriction on the preamble: since
it is copied into two different C output files, it must not contain
any definitions, only declarations. If a file contains both
definitions and declarations, then the two output files will produce
duplicate symbols and the linker will fail. To avoid this, definitions
must be placed in preambles in other files, or in C source files.

Ian


> On Thu, Dec 5, 2019 at 9:52 PM Dan Kortschak  wrote:
> >
> > Thanks. Can you explain the reason for this so it sticks in my head?
> >
> > On Thu, 2019-12-05 at 21:03 -0700, andrey mirtchovski wrote:
> > > you just need to split it in two files. the cfuncs go into another
> > > (sorry for lack of playground link):
> > >
> > > $ go build cgo.go cfunc.go
> > > $ ./cgo
> > > Hello from stdio
> > >
> > > $ cat cgo.go
> > > package main
> > >
> > > /*
> > > #include 
> > > extern void myprint(char *s);
> > > */
> > > import "C"
> > >
> > > import "unsafe"
> > >
> > > //export Example
> > > func Example() {
> > > cs := C.CString("Hello from stdio\n")
> > > C.myprint(cs)
> > > C.free(unsafe.Pointer(cs))
> > > }
> > >
> > > func main() {
> > > Example()
> > > }
> > > $ cat cfunc.go
> > > package main
> > >
> > > /*
> > > #include 
> > > #include 
> > >
> > > void myprint(char* s) {
> > > printf("%s\n", s);
> > > }
> > > */
> > > import "C"
> > >
> > > On Thu, Dec 5, 2019 at 8:47 PM Dan Kortschak 
> > > wrote:
> > > >
> > > > I am trying to write a shared module that will be called from C,
> > > > but I
> > > > have run into a problem in using the work-around in
> > > > https://github.com/golang/go/wiki/cgo#the-basics for calling
> > > > variadic C
> > > > functions.
> > > >
> > > > The case that I have is more complex, but altering the example at
> > > > the
> > > > wiki demonstrates the problem; the function definition that is used
> > > > to
> > > > call on to printf appears more than once in the C code generated by
> > > > Cgo.
> > > >
> > > > ```
> > > > ~/src/github.com/kortschak/cgo $ cat cgo.go
> > > > package main
> > > >
> > > > /*
> > > > #include 
> > > > #include 
> > > >
> > > > void myprint(char* s) {
> > > > printf("%s\n", s);
> > > > }
> > > > */
> > > > import "C"
> > > >
> > > > import "unsafe"
> > > >
> > > > //export Example
> > > > func Example() {
> > > > cs := C.CString("Hello from stdio\n")
> > > > C.myprint(cs)
> > > > C.free(unsafe.Pointer(cs))
> > > > }
> > > >
> > > > func main() {}
> > > > ~/src/github.com/kortschak/cgo $ go build -o cgo.so -buildmode=c-
> > > > shared
> > > > .
> > > > # github.com/kortschak/cgo
> > > > /tmp/go-build899365101/b001/_x002.o: In function `printf':
> > > > /usr/include/x86_64-linux-gnu/bits/stdio2.h:104: multiple
> > > > definition of
> > > > `myprint'
> > > > /tmp/go-build899365101/b001/_x001.o:/usr/include/x86_64-linux-
> > > > gnu/bits/stdio2.h:104: first defined here
> > > > collect2: error: ld returned 1 exit status
> > > > ```
> > > >
> > > > Removing the "//export Example" comment prevents this failure, but
> > > > then
> > > > obviously also loses the exported function. I have tried protecting
> > > > the
> > > > function in a #ifndef/#endif, to no avail.
> > > >
> > > > Is it reasonable for me to expect this to work? If so, what am I
> > > > doing
> > > > wrong?
> > > >
> > > > thanks
> > > > Dan
> > > >
> > > > --
> > > > 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/ab825669afe753c505952f18fb6c61bc8e2dd24d.camel%40kortschak.io
> > > > .
> >
>
> --
> 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/CAK4xykW1EiNZrXaytkrO%2BoiE4PQmF5ccDoc0b9aJgtMzXig8Bg%40mail.gmail.com.

-- 
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

Re: [go-nuts] cgo wrapper function not working in buildmode=c-shared with exported function

2019-12-05 Thread andrey mirtchovski 
i think cgo does some magic with defining functions called via
C.funcname. if you have the same func defined in the C preamble as
well as call it from the same Go file you get the same func defined
twice. putting it elsewhere as an extern seems to work.

to be honest i never dug into it. i did it once for callbacks in a
library in 2013 and forgot about it :) it just works.

On Thu, Dec 5, 2019 at 9:52 PM Dan Kortschak  wrote:
>
> Thanks. Can you explain the reason for this so it sticks in my head?
>
> On Thu, 2019-12-05 at 21:03 -0700, andrey mirtchovski wrote:
> > you just need to split it in two files. the cfuncs go into another
> > (sorry for lack of playground link):
> >
> > $ go build cgo.go cfunc.go
> > $ ./cgo
> > Hello from stdio
> >
> > $ cat cgo.go
> > package main
> >
> > /*
> > #include 
> > extern void myprint(char *s);
> > */
> > import "C"
> >
> > import "unsafe"
> >
> > //export Example
> > func Example() {
> > cs := C.CString("Hello from stdio\n")
> > C.myprint(cs)
> > C.free(unsafe.Pointer(cs))
> > }
> >
> > func main() {
> > Example()
> > }
> > $ cat cfunc.go
> > package main
> >
> > /*
> > #include 
> > #include 
> >
> > void myprint(char* s) {
> > printf("%s\n", s);
> > }
> > */
> > import "C"
> >
> > On Thu, Dec 5, 2019 at 8:47 PM Dan Kortschak 
> > wrote:
> > >
> > > I am trying to write a shared module that will be called from C,
> > > but I
> > > have run into a problem in using the work-around in
> > > https://github.com/golang/go/wiki/cgo#the-basics for calling
> > > variadic C
> > > functions.
> > >
> > > The case that I have is more complex, but altering the example at
> > > the
> > > wiki demonstrates the problem; the function definition that is used
> > > to
> > > call on to printf appears more than once in the C code generated by
> > > Cgo.
> > >
> > > ```
> > > ~/src/github.com/kortschak/cgo $ cat cgo.go
> > > package main
> > >
> > > /*
> > > #include 
> > > #include 
> > >
> > > void myprint(char* s) {
> > > printf("%s\n", s);
> > > }
> > > */
> > > import "C"
> > >
> > > import "unsafe"
> > >
> > > //export Example
> > > func Example() {
> > > cs := C.CString("Hello from stdio\n")
> > > C.myprint(cs)
> > > C.free(unsafe.Pointer(cs))
> > > }
> > >
> > > func main() {}
> > > ~/src/github.com/kortschak/cgo $ go build -o cgo.so -buildmode=c-
> > > shared
> > > .
> > > # github.com/kortschak/cgo
> > > /tmp/go-build899365101/b001/_x002.o: In function `printf':
> > > /usr/include/x86_64-linux-gnu/bits/stdio2.h:104: multiple
> > > definition of
> > > `myprint'
> > > /tmp/go-build899365101/b001/_x001.o:/usr/include/x86_64-linux-
> > > gnu/bits/stdio2.h:104: first defined here
> > > collect2: error: ld returned 1 exit status
> > > ```
> > >
> > > Removing the "//export Example" comment prevents this failure, but
> > > then
> > > obviously also loses the exported function. I have tried protecting
> > > the
> > > function in a #ifndef/#endif, to no avail.
> > >
> > > Is it reasonable for me to expect this to work? If so, what am I
> > > doing
> > > wrong?
> > >
> > > thanks
> > > Dan
> > >
> > > --
> > > 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/ab825669afe753c505952f18fb6c61bc8e2dd24d.camel%40kortschak.io
> > > .
>

-- 
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/CAK4xykW1EiNZrXaytkrO%2BoiE4PQmF5ccDoc0b9aJgtMzXig8Bg%40mail.gmail.com.

Re: [go-nuts] cgo wrapper function not working in buildmode=c-shared with exported function

2019-12-05 Thread Dan Kortschak 
Thanks. Can you explain the reason for this so it sticks in my head?

On Thu, 2019-12-05 at 21:03 -0700, andrey mirtchovski wrote:
> you just need to split it in two files. the cfuncs go into another
> (sorry for lack of playground link):
> 
> $ go build cgo.go cfunc.go
> $ ./cgo
> Hello from stdio
> 
> $ cat cgo.go
> package main
> 
> /*
> #include 
> extern void myprint(char *s);
> */
> import "C"
> 
> import "unsafe"
> 
> //export Example
> func Example() {
> cs := C.CString("Hello from stdio\n")
> C.myprint(cs)
> C.free(unsafe.Pointer(cs))
> }
> 
> func main() {
> Example()
> }
> $ cat cfunc.go
> package main
> 
> /*
> #include 
> #include 
> 
> void myprint(char* s) {
> printf("%s\n", s);
> }
> */
> import "C"
> 
> On Thu, Dec 5, 2019 at 8:47 PM Dan Kortschak 
> wrote:
> > 
> > I am trying to write a shared module that will be called from C,
> > but I
> > have run into a problem in using the work-around in
> > https://github.com/golang/go/wiki/cgo#the-basics for calling
> > variadic C
> > functions.
> > 
> > The case that I have is more complex, but altering the example at
> > the
> > wiki demonstrates the problem; the function definition that is used
> > to
> > call on to printf appears more than once in the C code generated by
> > Cgo.
> > 
> > ```
> > ~/src/github.com/kortschak/cgo $ cat cgo.go
> > package main
> > 
> > /*
> > #include 
> > #include 
> > 
> > void myprint(char* s) {
> > printf("%s\n", s);
> > }
> > */
> > import "C"
> > 
> > import "unsafe"
> > 
> > //export Example
> > func Example() {
> > cs := C.CString("Hello from stdio\n")
> > C.myprint(cs)
> > C.free(unsafe.Pointer(cs))
> > }
> > 
> > func main() {}
> > ~/src/github.com/kortschak/cgo $ go build -o cgo.so -buildmode=c-
> > shared
> > .
> > # github.com/kortschak/cgo
> > /tmp/go-build899365101/b001/_x002.o: In function `printf':
> > /usr/include/x86_64-linux-gnu/bits/stdio2.h:104: multiple
> > definition of
> > `myprint'
> > /tmp/go-build899365101/b001/_x001.o:/usr/include/x86_64-linux-
> > gnu/bits/stdio2.h:104: first defined here
> > collect2: error: ld returned 1 exit status
> > ```
> > 
> > Removing the "//export Example" comment prevents this failure, but
> > then
> > obviously also loses the exported function. I have tried protecting
> > the
> > function in a #ifndef/#endif, to no avail.
> > 
> > Is it reasonable for me to expect this to work? If so, what am I
> > doing
> > wrong?
> > 
> > thanks
> > Dan
> > 
> > --
> > 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/ab825669afe753c505952f18fb6c61bc8e2dd24d.camel%40kortschak.io
> > .

-- 
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/0c5b3d1d0df8a0baf061f0db174f540fe48b198a.camel%40kortschak.io.

Re: [go-nuts] cgo wrapper function not working in buildmode=c-shared with exported function

2019-12-05 Thread andrey mirtchovski 
you just need to split it in two files. the cfuncs go into another
(sorry for lack of playground link):

$ go build cgo.go cfunc.go
$ ./cgo
Hello from stdio

$ cat cgo.go
package main

/*
#include 
extern void myprint(char *s);
*/
import "C"

import "unsafe"

//export Example
func Example() {
cs := C.CString("Hello from stdio\n")
C.myprint(cs)
C.free(unsafe.Pointer(cs))
}

func main() {
Example()
}
$ cat cfunc.go
package main

/*
#include 
#include 

void myprint(char* s) {
printf("%s\n", s);
}
*/
import "C"

On Thu, Dec 5, 2019 at 8:47 PM Dan Kortschak  wrote:
>
> I am trying to write a shared module that will be called from C, but I
> have run into a problem in using the work-around in
> https://github.com/golang/go/wiki/cgo#the-basics for calling variadic C
> functions.
>
> The case that I have is more complex, but altering the example at the
> wiki demonstrates the problem; the function definition that is used to
> call on to printf appears more than once in the C code generated by
> Cgo.
>
> ```
> ~/src/github.com/kortschak/cgo $ cat cgo.go
> package main
>
> /*
> #include 
> #include 
>
> void myprint(char* s) {
> printf("%s\n", s);
> }
> */
> import "C"
>
> import "unsafe"
>
> //export Example
> func Example() {
> cs := C.CString("Hello from stdio\n")
> C.myprint(cs)
> C.free(unsafe.Pointer(cs))
> }
>
> func main() {}
> ~/src/github.com/kortschak/cgo $ go build -o cgo.so -buildmode=c-shared
> .
> # github.com/kortschak/cgo
> /tmp/go-build899365101/b001/_x002.o: In function `printf':
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:104: multiple definition of
> `myprint'
> /tmp/go-build899365101/b001/_x001.o:/usr/include/x86_64-linux-
> gnu/bits/stdio2.h:104: first defined here
> collect2: error: ld returned 1 exit status
> ```
>
> Removing the "//export Example" comment prevents this failure, but then
> obviously also loses the exported function. I have tried protecting the
> function in a #ifndef/#endif, to no avail.
>
> Is it reasonable for me to expect this to work? If so, what am I doing
> wrong?
>
> thanks
> Dan
>
> --
> 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/ab825669afe753c505952f18fb6c61bc8e2dd24d.camel%40kortschak.io.

-- 
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/CAK4xykURExDvQ6L-rGSx0fJcq9STha16u%2BqKEXp4PjgP3aau3w%40mail.gmail.com.

[go-nuts] cgo wrapper function not working in buildmode=c-shared with exported function

2019-12-05 Thread Dan Kortschak 
I am trying to write a shared module that will be called from C, but I
have run into a problem in using the work-around in 
https://github.com/golang/go/wiki/cgo#the-basics for calling variadic C
functions.

The case that I have is more complex, but altering the example at the
wiki demonstrates the problem; the function definition that is used to
call on to printf appears more than once in the C code generated by
Cgo.

```
~/src/github.com/kortschak/cgo $ cat cgo.go 
package main

/*
#include 
#include 

void myprint(char* s) {
printf("%s\n", s);
}
*/
import "C"

import "unsafe"

//export Example
func Example() {
cs := C.CString("Hello from stdio\n")
C.myprint(cs)
C.free(unsafe.Pointer(cs))
}

func main() {}
~/src/github.com/kortschak/cgo $ go build -o cgo.so -buildmode=c-shared 
.
# github.com/kortschak/cgo
/tmp/go-build899365101/b001/_x002.o: In function `printf':
/usr/include/x86_64-linux-gnu/bits/stdio2.h:104: multiple definition of
`myprint'
/tmp/go-build899365101/b001/_x001.o:/usr/include/x86_64-linux-
gnu/bits/stdio2.h:104: first defined here
collect2: error: ld returned 1 exit status
```

Removing the "//export Example" comment prevents this failure, but then
obviously also loses the exported function. I have tried protecting the
function in a #ifndef/#endif, to no avail.

Is it reasonable for me to expect this to work? If so, what am I doing
wrong?

thanks
Dan

-- 
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/ab825669afe753c505952f18fb6c61bc8e2dd24d.camel%40kortschak.io.

Re: [go-nuts] Looking for an app w/ mult. versions of a dependency

2019-12-05 Thread Andy Balholm 
I’m pretty sure there is no “otherwise simple” example, because depending on 
two versions of the same library isn’t usually something a project does 
deliberately (except as a last resort). It’s normally the consequence of an 
extremely complex forest of dependencies.

Andy

> On Dec 5, 2019, at 5:52 PM, George Hartzell  wrote:
> 
> 
> Hi All,
> 
> I'm working on improving the Spack (https://spack.io) package managers
> support for Go-based application
> (https://github.com/spack/spack/issues/13023).
> 
> I'm trying to wrap my head around what Go's support for simultaneously
> using multiple major versions of a dependency means to Spack.
> 
> To that end, I'm looking for an otherwise simple application that uses
> Go modules and depends on multiple versions of some library.  I've
> done a bit of searching but have come up dry.
> 
> I'm wondering if any of you other nuts can point out examples?
> 
> Thanks,
> 
> g.
> 
> -- 
> 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/24041.46159.307729.108343%40alice.local.

-- 
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/E809B0DE-82E7-4C0B-A3D0-572EB3FAA7FE%40gmail.com.

[go-nuts] Looking for an app w/ mult. versions of a dependency

2019-12-05 Thread George Hartzell 


Hi All,

I'm working on improving the Spack (https://spack.io) package managers
support for Go-based application
(https://github.com/spack/spack/issues/13023).

I'm trying to wrap my head around what Go's support for simultaneously
using multiple major versions of a dependency means to Spack.

To that end, I'm looking for an otherwise simple application that uses
Go modules and depends on multiple versions of some library.  I've
done a bit of searching but have come up dry.

I'm wondering if any of you other nuts can point out examples?

Thanks,

g.

-- 
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/24041.46159.307729.108343%40alice.local.

[go-nuts] Re: [ANN] Arhat: an experimental deep learning framework implemented in Go

2019-12-05 Thread Tong Sun 


On Monday, December 2, 2019 at 12:56:14 PM UTC-5, Alexey wrote:
>
> I would like to announce the first public release of Arhat, an 
> experimental deep learning framework implemented in Go.
>
> Unlike most mainstream frameworks that perform training and inference 
> computations directly, Arhat translates neural network descriptions into 
> standalone lean executable platform-specific code. 
>

That's a super good idea. Just curious, what type of neural network 
descriptions input does it take?
 

> This approach allows direct embedding of the generated code into user 
> applications and does not require deployment of sophisticated machine 
> learning software stacks on the target platforms.
>
> We at Fragata use Arhat as a research platform for our larger ongoing 
> project aiming at construction of a production-grade machine learning 
> framework optimized for use on embedded platforms and massively parallel 
> supercomputers.
>
> The project repository is located here:
>
> https://github.com/fragata-ai/arhat
>
>
>

-- 
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/e339b818-023f-45cf-aa32-ff4f41b18b2e%40googlegroups.com.

[go-nuts] Re: Is a public go benchmarking database/dashboard available

2019-12-05 Thread Tong Sun 


On Monday, December 2, 2019 at 10:33:25 PM UTC-5, Xiangdong JI wrote:
>
> Hi,
>
> Wondering if there is any public database/dashboard of Go's benchmarking 
> data available? Thanks.
>

And by "public database" you meant a central one that covers everything? 
I.e., the purpose of benchmarking varies dramatically, please elaborate why 
you would think a cover-it-all one is a good idea. 


-- 
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/035f11da-b932-4f98-b753-b258684652c6%40googlegroups.com.

[go-nuts] Plot Go's benchmark result

2019-12-05 Thread Tong Sun 
Hi, 

Any existing tools out there that can turn Go's benchmark result from text 
into chart? 

I'm looking for a simple/light-weighted solution, like using gnuplot, or 
web --
Found one using Python to plot Go's benchmark result, but don't like the 
overhead. 

thx

-- 
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/c737f2d5-cc55-4ddc-a905-9c443d3916c8%40googlegroups.com.

Re: [go-nuts] tricks for installing go a single time on Windows 10 with Bash for Windows

2019-12-05 Thread Bruno Albuquerque 
Can you clarify what exactly your problem is? I am asking because the only
configuration that should be needed for go is to make sure it is in your
system path (which mishandled by the installer). There is nothing else that
you *MUST* configure for it to work.

What is the actual problem you are having?


On Thu, Dec 5, 2019 at 4:17 PM Pat Farrell  wrote:

>
> On Thursday, December 5, 2019 at 12:27:20 PM UTC-5, Rodrick Brown wrote:
>>
>> The first thing
>>
>
> Thanks. But that was not what I was asking for.
> I have the shells working. But go's installation has a lot of config stuff
> that needs to be setup.
> I want to have go work the same no matter which shell I am using. Sadly,
> the shells are separate, so things like logical links, paths, etc have to
> be redone for each of them. This is clearly an obvious bugfarm as its easy
> to setup a config say in bash that is different from the cmd.exe or
> powershell config.
>
> --
> 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/aa2f0011-a75e-4c6e-954a-25f2a9cdca30%40googlegroups.com
> 
> .
>

-- 
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/CAEd86Tz1zmLnEhSbUOJ5ptFSaWt0u3ugf-KpFrLGoyDPekzKfg%40mail.gmail.com.

Re: [go-nuts] tricks for installing go a single time on Windows 10 with Bash for Windows

2019-12-05 Thread Pat Farrell 

On Thursday, December 5, 2019 at 12:27:20 PM UTC-5, Rodrick Brown wrote:
>
> The first thing
>

Thanks. But that was not what I was asking for.
I have the shells working. But go's installation has a lot of config stuff 
that needs to be setup.
I want to have go work the same no matter which shell I am using. Sadly, 
the shells are separate, so things like logical links, paths, etc have to 
be redone for each of them. This is clearly an obvious bugfarm as its easy 
to setup a config say in bash that is different from the cmd.exe or 
powershell config. 

-- 
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/aa2f0011-a75e-4c6e-954a-25f2a9cdca30%40googlegroups.com.

[go-nuts] golang on z/os

2019-12-05 Thread tpfaff100 
Are there any complete distros for golang 1.x on Z/OS?
It seems that an IBM group in china had it working but is currently not 
supporting it.

The "raleigh" server at IBM seems to be down so cross-compiling it has 
become not possible.
Is there anyone here who knows where the distributions are?

Regards,
Thomas

-- 
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/878276b8-4a2d-4f24-a094-c16b8b25ab3d%40googlegroups.com.

Re: [go-nuts] log may block the entire program if stderr pipe gets full

2019-12-05 Thread Robert Engels 
Nothing to be done here. This is the expected behavior and has been that way 
since the start of Unix. 

You can get around this by piping to an intermediate process that spools to 
disk and reads from that - until you run out of disk space. 

Honestly you probably should fix the consumer. 

> On Dec 5, 2019, at 11:27 AM, peter.juhas...@gmail.com wrote:
> 
> 
> I've run into an insidious issue.
> 
> The log package writes to the standard error. However, at least on linux, if 
> stderr is redirected to a pipe and the other end of that pipe is not drained, 
> then the kernel buffer associated with that pipe eventually gets full, and 
> once that happens, subsequent write calls to stderr will block indefinitely. 
> The problem is exacerbated by the fact that the log package uses a mutex to 
> ensure that messages don't get mixed up on output - but because the of the 
> blocked write call the mutex is never unlocked, so any subsequent call to any 
> output function of the log package, from anywhere in the program, will block.
> 
> Demonstration: the following program, when ran in itself, prints several 
> dummy strings to stderr then exits with a panic message.
> 
> //
> package main
> 
> import (
> "log"
> "time"
> )
> 
> func spam(id int) {
> max := 1
> for i := 0; i < max; i++ {
> log.Printf("%d\t%06d\t%10s", id, i, "")
> }
> }
> 
> func main() {
> go spam(1)
> go spam(2)
> time.Sleep(1 * time.Second)
> panic("exiting")
> }
> //
> 
> However, when ran through the following script, which redirects the standard 
> error of its child process but purposely doesn't read from it, the program 
> hangs.
> 
> 
> #!/usr/bin/perl
> 
> use strict;
> use warnings;
> use IPC::Open3;
> use Symbol 'gensym';
> 
> my($wtr, $rdr, $err);
> $err = gensym;
> my $pid = open3($wtr, $rdr, $err, @ARGV);
> 
> waitpid( $pid, 0 );
> ##
> 
> (Compile the above go program as `child`, save this script as runner.pl, then 
> run it as `perl runner.pl ./child`.)
> If you run it with strace, you can see that it can't even panic, because it 
> blocks on one of the many write calls that produce the panic message.
> 
> 
> The question of "but why would you do that" may arise - of course I would not 
> *want* to do this. The issue came up in an environment where a go program 
> somewhat more complex than the one above is run by supervisord, and I use 
> supervisord's output redirection facility to forward the go program's stderr 
> to a remote syslog sink. And, for some reason I don't yet understand, 
> supervisord stopped reading the stderr pipe mid-run.
> So I don't say that this is a bug in go, I'm not sure that you could even do 
> anything about it, I just find the issue particularly annoying, because it's 
> hard to detect and hard to work around.
> Perhaps a note in the log package's documentation about possible dangers of 
> redirecting stderr may be useful.
> 
> best regards,
> Peter Juhasz
> 
> -- 
> 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/83a396b3-41c1-453d-b604-3640ba58bdb0%40googlegroups.com.

-- 
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/8CABDBE5-11C5-48EC-A4EA-864C3B924B70%40ix.netcom.com.

Re: [go-nuts] tricks for installing go a single time on Windows 10 with Bash for Windows

2019-12-05 Thread Rodrick Brown 
The first thing you need to do is to enable Windows Subsystem for Linux
feature from PowerShell.
Go to the Start menu and search for PowerShell. Run it as administrator:
Once you have the PowerShell running, use the command below to enable Bash
in Windows 10.
Enable-WindowsOptionalFeature -Online -FeatureName
Microsoft-Windows-Subsystem-Linux
You’ll be asked to confirm your choice. Type Y or press enter:

Step 2: Download a Linux system from the Windows store
Once your system has rebooted, go to the Windows Store and search for
“Linux.”
You’ll see the option to install Ubuntu or SUSE.

On Thu, Dec 5, 2019 at 12:53 AM Pat Farrell  wrote:

> I've got a new machine. I run Windows 10, but use bash all the time for
> all my command line stuff, and running vim, etc.
> When I did it on the prior machine, it was a fairly large pain to get go
> to work properly in all the environments, the special go shell, PowerShell,
> bash, etc.
>
> I'd like to do it directly and cleanly this time.
>
> Any tips and tricks I should know about?
>
> --
> 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/9c41b516-60a1-44e8-9b90-9cb5f65c8278%40googlegroups.com
> 
> .
>

-- 
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/CABRP1o_PN471pMh3Wi6W6oZ%3D5WKzpCujFLiV-nm3a_8p9ADZSA%40mail.gmail.com.

[go-nuts] Re: golang gcc c++ existing static library can not be used when making a PIE object; recompile with -fPIC

2019-12-05 Thread nju04zq 
I also run into this problem these days. Finally I found that adding "env 
CGO_LDFLAGS=-no-pie" to go build command line could solve this problem. For 
example, "env CGO_LDFLAGS=-no-pie go build -o main main.go".

On Monday, July 1, 2019 at 8:22:08 AM UTC+8, czha...@gmail.com wrote:
>
> I posted this question in SO, and was suggested to post here for more help:
>
>
> --
>
> I tried to link an existing C++ library to go code. The C++ library only 
> has a static library and a header file, no source code.
>
> I used swigc to generate a libfoo.go and I wrote a simple libb.go to build 
> this library. This worked well on ubuntu 16.04 with gcc-6 earlier.
>
> However, once I upgraded to ubuntu 18, and even with older go1.9 and 
> gcc-6, which used to work, I am hitting the following error:
>
> /usr/bin/ld: ./lib/libfoo.a(parser.o): relocation R_X86_64_32S against symbol 
> `xmlSAX2IgnorableWhitespace' can not be used when making a PIE object; 
> recompile with -fPIC
> /usr/bin/ld: ./lib/libfoo.a(tree.o): relocation R_X86_64_32 against 
> `.rodata.str1.1' can not be used when making a PIE object; recompile with 
> -fPIC
>
> I have downgraded both go compiler and gcc to the version that used to 
> work.
>
> The following is the libb.go that used to work
>
> /*
> #cgo CXXFLAGS: -std=c++11 -D_GLIBCXX_USE_CXX11_ABI=0 -w
> #cgo CFLAGS: -I${SRCDIR}/include -w
> #cgo LDFLAGS: -Wl -rpath,./lib, -L${SRCDIR}/lib -l:libfoo.a  -l:libxml2.a 
> */import "C"
>
> What should I do get this fixed? I searched and it seems that I have to 
> recompile that static library, which is mission impossible in my case. I 
> tried to pass the -no-pie parameter to LDFLAGS, that didn't work either.
>
>
>
> Thanks!
>
> --
>
>
> 1, first thing first, I don't have the c++ source code, so I can't 
> recompile it. 
>
> 2, I am using ubuntu 18, initially, I believe I install go via "apt-get 
> install", but later I uninstall that version using "apt-get remove" , and 
> then downloaded go1.9 pkg from official website and install directly. 
>
> 3, go env gives:
>
> GOARCH="amd64"
>
> GOBIN=""
>
> GOEXE=""
>
> GOHOSTARCH="amd64"
>
> GOHOSTOS="linux"
>
> GOOS="linux"
>
> GOPATH="/home/coolart/work/go"
>
> GORACE=""
>
> GOROOT="/usr/local/go"
>
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
>
> GCCGO="gccgo"
>
> CC="gcc"
>
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=/tmp/go-build628698308=/tmp/go-build 
> -gno-record-gcc-switches"
>
> CXX="g++"
>
> CGO_ENABLED="1"
>
> CGO_CFLAGS="-g -O2"
>
> CGO_CPPFLAGS=""
>
> CGO_CXXFLAGS="-g -O2"
>
> CGO_FFLAGS="-g -O2"
>
> CGO_LDFLAGS="-g -O2"
>
> PKG_CONFIG="pkg-config"
>
>
> 4, some system information
>
>
> go version go1.9.7 linux/amd64
>
>
> No LSB modules are available.
>
> Distributor ID: Ubuntu
>
> Description: Ubuntu 18.04.2 LTS
>
> Release: 18.04
>
> Codename: bionic
>
>
> Using built-in specs.
>
> COLLECT_GCC=gcc
>
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
>
> Target: x86_64-linux-gnu
>
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
> 5.5.0-12ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
> --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-5 --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object 
> --disable-vtable-verify --enable-libmpx --enable-plugin 
> --enable-default-pie --with-system-zlib --enable-objc-gc --enable-multiarch 
> --disable-werror --with-arch-32=i686 --with-abi=m64 
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
> --target=x86_64-linux-gnu
>
> Thread model: posix
>
> gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1)
>
>
> Using built-in specs.
>
> COLLECT_GCC=g++
>
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
>
> Target: x86_64-linux-gnu
>
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
> 5.5.0-12ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
> --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-5 --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object 
> --disable-vtable-verify --enable-libmpx --enable-plugin 
> --enable-default-pie --with-system-zlib --enable-objc-gc --enable-multiarch 
> --disable-werror --with-arch-32=i686 --with-abi=m64 
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
>

[go-nuts] log may block the entire program if stderr pipe gets full

2019-12-05 Thread peter . juhasz83 
I've run into an insidious issue.

The log package writes to the standard error. However, at least on linux, 
if stderr is redirected to a pipe and the other end of that pipe is not 
drained, then the kernel buffer associated with that pipe eventually gets 
full, and once that happens, subsequent write calls to stderr will block 
indefinitely. The problem is exacerbated by the fact that the log package 
uses a mutex to ensure that messages don't get mixed up on output - but 
because the of the blocked write call the mutex is never unlocked, so any 
subsequent call to any output function of the log package, from anywhere in 
the program, will block.

Demonstration: the following program, when ran in itself, prints several 
dummy strings to stderr then exits with a panic message.

//
package main

import (
"log"
"time"
)

func spam(id int) {
max := 1
for i := 0; i < max; i++ {
log.Printf("%d\t%06d\t%10s", id, i, "")
}
}

func main() {
go spam(1)
go spam(2)
time.Sleep(1 * time.Second)
panic("exiting")
}
//

However, when ran through the following script, which redirects the 
standard error of its child process but purposely doesn't read from it, the 
program hangs.


#!/usr/bin/perl

use strict;
use warnings;
use IPC::Open3;
use Symbol 'gensym';

my($wtr, $rdr, $err);
$err = gensym;
my $pid = open3($wtr, $rdr, $err, @ARGV);

waitpid( $pid, 0 );
##

(Compile the above go program as `child`, save this script as runner.pl, 
then run it as `perl runner.pl ./child`.)
If you run it with strace, you can see that it can't even panic, because it 
blocks on one of the many write calls that produce the panic message.


The question of "but why would you do that" may arise - of course I would 
not *want* to do this. The issue came up in an environment where a go 
program somewhat more complex than the one above is run by supervisord, and 
I use supervisord's output redirection facility to forward the go program's 
stderr to a remote syslog sink. And, for some reason I don't yet 
understand, supervisord stopped reading the stderr pipe mid-run.
So I don't say that this is a bug in go, I'm not sure that you could even 
do anything about it, I just find the issue particularly annoying, because 
it's hard to detect and hard to work around.
Perhaps a note in the log package's documentation about possible dangers of 
redirecting stderr may be useful.

best regards,
Peter Juhasz

-- 
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/83a396b3-41c1-453d-b604-3640ba58bdb0%40googlegroups.com.

[go-nuts] manifest file of releases

2019-12-05 Thread uldericofilho 
Hi,


I did a quick investigation but I could not find a post that confirms 
whether there is a machine-friendly URL for Go releases?

I would hope there would be a JSON file from which I could use to monitor 
releases and obtain download URLs. Something similar to what CoreOS does:
https://coreos.com/releases/releases.json


Thanks,
Ulderico

-- 
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/1bb74609-cfa1-4f49-a873-2663b6e14f04%40googlegroups.com.

[go-nuts] Multiple processes in parallel for cgo service

2019-12-05 Thread Nitish Saboo 
Hi,

I am having a cgo(go + c) service.Is it possible to run multiple processes 
of the same service in parallel ?

Thanks,
Nitish

-- 
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/7d4f24d2-bacc-44f0-9062-7b1f3be65e2d%40googlegroups.com.

[go-nuts] Re: GOMAXPROCS > num of CPU

2019-12-05 Thread Vincent Blanchon 
Hello Serhat,


Yes, I do not see a use case either. This is why I opened this thread, to 
know if someone sees a use case since it has been mentioned on GitHub :)



Le jeudi 5 décembre 2019 11:33:10 UTC+4, Serhat Şevki Dinçer a écrit :
>
> In runtime it says:
>
> The GOMAXPROCS variable limits the number of operating system threads that 
> can execute user-level Go code simultaneously. There is no limit to the 
> number of threads that can be blocked in system calls on behalf of Go code; 
> those do not count against the GOMAXPROCS limit. This package's GOMAXPROCS 
> function queries and changes the limit.
>
> So normally it does not make sense to increase it beyond available 
> physical "HW threads" (I think this is what you meant with cpu) count 
> (since blocked threads do not count towards this limit).
> As long as "active thread accounting" is accurate in the OS, I dont see 
> any reason to set it higher. I think it is easy to test >HWthreads effects 
> with a concurrent cpu-intensive job.
>
> On Wednesday, December 4, 2019 at 8:24:13 PM UTC+3, Vincent Blanchon wrote:
>>
>> Hello,
>>
>>
>> I've read on GitHub (
>> https://github.com/golang/go/issues/20303#issuecomment-329418911) "there 
>> are good reasons" to set GOMAXPROCS to > num CPU.
>> Just out of curiosity, I want to know if someone has an example of it or 
>> any good reason to set it up more than the number of CPUs?
>>
>> Thanks
>>
>

-- 
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/e281fe24-26f2-4a20-89ee-b43888c557c2%40googlegroups.com.