Re: [go-nuts] How to handle EINTR from syscall.Dup2

[Philip Boampong]

Thanks for the reply.

> Note that dup2() can only fail with EINTR if the new fd is currently open on 
> a "slow" device and the implicit close() fails due to being interrupted.

I understand the condition may be rare, but I still want to know the
correct way to handle it.

> In my experience it is usually an error if the new fd is currently in use 
> unless the new fd is 0, 1 or 2 .

The Go programmer is not fully in charge of the FD namespace:
libraries and the runtime can create new FDs at any time. Therefore,
unless you are sure that newfd *is* in use and know exactly what it
is, you are probably looking for trouble.

> If you expect the new fd to be in use at the time of the dup2() it is usually 
> better, from the viewpoint of clarity, to incur the cost of an explicit 
> close() call.

That seems very dangerous, especially in Go.
If another goroutine opens a file between the close and the dup2, such
open will likely reuse newfd which is about to be replaced. Then the
second goroutine will have the wrong file and operate concurrently on
it.
Atomicity with close is the whole point of dup2.

> So your question is really what to do if close() fails with EINTR and the 
> answer is retry.

The man page [1] explicitly says that Linux close(2) should *never* be
retried, not even on EINTR.
As I mentioned, there are plans to change close to return EINPROGRESS,
or even no error at all, instead of EINTR [2].

[1] http://man7.org/linux/man-pages/man2/close.2.html
[2] https://lwn.net/Articles/576478/

-- 
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/CAEvMKD-UCrAb7-BXy8Q6Bs4L%2Bn-MLptt5zS50XjQcy0FPSHsxw%40mail.gmail.com.

Re: [go-nuts] How to handle EINTR from syscall.Dup2

[Kurtis Rader]

On Fri, Feb 28, 2020 at 12:41 PM  wrote:

> What to do on EINTR from syscall.Dup2 (Linux)?
>
> 1) It never happen.
> 2) Retry.
> 3) Take it as irrecoverable.
> 4) Take it as success.
>
> I know this is more of an OS question, but it all started with the
> asynchronous preemption announcement, and I don't know where else to get
> help.
>

Note that dup2() can only fail with EINTR if the new fd is currently open
on a "slow" device and the implicit close() fails due to being interrupted.
In my experience it is usually an error if the new fd is currently in use
unless the new fd is 0, 1 or 2 . If you expect the new fd to be in use at
the time of the dup2() it is usually better, from the viewpoint of clarity,
to incur the cost of an explicit close() call. If the new fd isn't in use
then dup2() is atomic and will never fail with EINTR. So your question is
really what to do if close() fails with EINTR and the answer is retry.
However, in practice the only situation where EINTR will happen on close()
is if the fd is open on a remote file system; e.g., a NFS mounted file
system. Even that is extremely unlikely unless there is a problem with the
network or remote file server in which case retrying is unlikely to succeed.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9RgrWhdt0XaetEyqmNzNkOLjqAGvfThdVGdeMKDsgBRA%40mail.gmail.com.

[go-nuts] How to handle EINTR from syscall.Dup2

[pboampong5]

(I've asked the same question already, but probably in the wrong thread, 
sorry for the repost.)

What to do on EINTR from syscall.Dup2 (Linux)?

1) It never happen.
2) Retry.
3) Take it as irrecoverable.
4) Take it as success.

I know this is more of an OS question, but it all started with the 
asynchronous preemption announcement, and I don't know where else to get 
help.

In the signal(7) man page, dup2 is neither mentioned in the "affected by 
SA_RESTART" list, nor in the other list. Is it affected or not?

According to [1][2], dup2 can close newfd and still fail, therefore it 
should *never* be retried because a retry would cause a dangerous race.
This would mean that a signal during dup2 (nothing out of the ordinary) 
would produce an irrecoverable condition!
The man page says that close+dup is done "atomically", but it isn't clear 
whether "close and fail" is a possibility or not.

Someone also hypothesizes that EINTR from dup2 can actually mean success, 
because it comes from the implicit close(2) and EINTR from close is not a 
failure indication on Linux (there are plans to change it to EINPROGRESS), 
see also [3][4].

I hope someone can shed some light on this,
thanks.

[1] https://github.com/libuv/libuv/issues/462
[2] https://www.python.org/dev/peps/pep-0475
[3] 
https://stackoverflow.com/questions/15930013/can-dup2-really-return-eintr
[4] https://lwn.net/Articles/576478

-- 
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/ec07c211-4b69-4791-9e8f-1b4122130424%40googlegroups.com.

[go-nuts] Re: modules and my v2 package only partly appearing on go.dev

[Paul Hankin]

On Friday, 28 February 2020 21:04:04 UTC+1, Paul Hankin wrote:
>
> On Friday, 28 February 2020 20:43:16 UTC+1, Paul Hankin wrote:
>>
>> I am rather confused about modules, and have trouble making them work.
>>
>> I have a package: https://github.com/paulhankin/poker
>>
>> The go.mod looks like this: `
>> module github.com/paulhankin/poker/v2
>>
>> go 1.13
>> `
>>
>> The package has a v1, and v2. At v2, I moved the main part of the package 
>> into a subdirectory "poker" so the import would be "
>> github.com/paulhankin/poker/v2/poker" rather than "
>> github.com/paulhankin/poker/v2".
>>
>> I can successfully import the v2 package in a new modules-aware project, 
>> and goproxy seems to pick up new versions:
>>
>> $ go list -m --versions
>> github.com/paulhankin/poker/v2 v2.0.0 v2.0.2 v2.0.3 v2.0.4 v2.0.5 v2.0.6 
>> v2.0.7
>>
>>
>> I can't find the documentation on go.dev though. The closest I can find 
>> is this:
>> https://pkg.go.dev/github.com/paulhankin/poker/v2
>> which contains the cmd subdirectory, but not the poker subdirectory.
>>
>> Am I doing something wrong? Did I make a mistake in moving the package 
>> into a subdirectory, or is there an easier way to avoid the import name 
>> being "v2"?
>>
>> I'd file a bug against go.dev if I thought it was broken, but I find 
>> modules so complicated that I don't know if it's my understanding that's 
>> wrong, or if I made a mistake, or if go.dev isn't working correctly. I'm 
>> pretty frustrated with the experience so far.
>>
>
> Oh, I see the problem. I created the subdirectory after tagging v2.0.0.
>

I deleted the tag, and go.dev has removed the v2.0.0 release, but the 
package /poker is still not showing up on 
https://pkg.go.dev/mod/github.com/paulhankin/poker/v2?tab=packages

Can someone please help?

-- 
Paul Hankin 

-- 
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/c1ecf162-dd8e-4262-9a66-3c400dcafd60%40googlegroups.com.

[go-nuts] Re: modules and my v2 package only partly appearing on go.dev

[Paul Hankin]

On Friday, 28 February 2020 20:43:16 UTC+1, Paul Hankin wrote:
>
> I am rather confused about modules, and have trouble making them work.
>
> I have a package: https://github.com/paulhankin/poker
>
> The go.mod looks like this: `
> module github.com/paulhankin/poker/v2
>
> go 1.13
> `
>
> The package has a v1, and v2. At v2, I moved the main part of the package 
> into a subdirectory "poker" so the import would be "
> github.com/paulhankin/poker/v2/poker" rather than "
> github.com/paulhankin/poker/v2".
>
> I can successfully import the v2 package in a new modules-aware project, 
> and goproxy seems to pick up new versions:
>
> $ go list -m --versions
> github.com/paulhankin/poker/v2 v2.0.0 v2.0.2 v2.0.3 v2.0.4 v2.0.5 v2.0.6 
> v2.0.7
>
>
> I can't find the documentation on go.dev though. The closest I can find 
> is this:
> https://pkg.go.dev/github.com/paulhankin/poker/v2
> which contains the cmd subdirectory, but not the poker subdirectory.
>
> Am I doing something wrong? Did I make a mistake in moving the package 
> into a subdirectory, or is there an easier way to avoid the import name 
> being "v2"?
>
> I'd file a bug against go.dev if I thought it was broken, but I find 
> modules so complicated that I don't know if it's my understanding that's 
> wrong, or if I made a mistake, or if go.dev isn't working correctly. I'm 
> pretty frustrated with the experience so far.
>

Oh, I see the problem. I created the subdirectory after tagging v2.0.0.

-- 
Paul Hankin

-- 
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/21888ea2-b3a6-4340-adaa-2d8f9c07402e%40googlegroups.com.

[go-nuts] modules and my v2 package only partly appearing on go.dev

[Paul Hankin]

I am rather confused about modules, and have trouble making them work.

I have a package: https://github.com/paulhankin/poker

The go.mod looks like this: `
module github.com/paulhankin/poker/v2

go 1.13
`

The package has a v1, and v2. At v2, I moved the main part of the package 
into a subdirectory "poker" so the import would be 
"github.com/paulhankin/poker/v2/poker" rather than 
"github.com/paulhankin/poker/v2".

I can successfully import the v2 package in a new modules-aware project, 
and goproxy seems to pick up new versions:

$ go list -m --versions
github.com/paulhankin/poker/v2 v2.0.0 v2.0.2 v2.0.3 v2.0.4 v2.0.5 v2.0.6 
v2.0.7


I can't find the documentation on go.dev though. The closest I can find is 
this:
https://pkg.go.dev/github.com/paulhankin/poker/v2
which contains the cmd subdirectory, but not the poker subdirectory.

Am I doing something wrong? Did I make a mistake in moving the package into 
a subdirectory, or is there an easier way to avoid the import name being 
"v2"?

I'd file a bug against go.dev if I thought it was broken, but I find 
modules so complicated that I don't know if it's my understanding that's 
wrong, or if I made a mistake, or if go.dev isn't working correctly. I'm 
pretty frustrated with the experience so far.

Thanks,
Paul Hankin

-- 
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/44b8db77-42fd-42cb-8dcc-8788c3d0e69b%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Ian Lance Taylor]

On Fri, Feb 28, 2020 at 9:39 AM Manlio Perillo  wrote:
>
> On Friday, February 28, 2020 at 6:29:56 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, Feb 28, 2020 at 9:14 AM Manlio Perillo  wrote:
>> >
>> > On Friday, February 28, 2020 at 5:36:09 PM UTC+1, Ian Lance Taylor wrote:
>> >>
>> >> On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo  
>> >> wrote:
>> >> >
>> > [...]
>>
>> >>  Go programs always
>> >> have multiple threads of execution.  Just let a goroutine sit in the
>> >> slow syscall; who cares?
>> >>
>> >
>> > An user running a client program from a terminal may care.
>> > If it takes too long to read data from a remote server, an user expects 
>> > that ^C will interrupt the program.
>> >
>> > However a solution is to register an atexit handler using a closure to do 
>> > some cleanup, so probably this is not an issue worth making the Go runtime 
>> > more complex.
>>
>> In Go, a ^C will interrupt a program if you write code like
>>
>> c := make(chan os.Signal, 1)
>> signal.Notify(c, syscall.SIGINT)
>> go func() {
>> <-c
>> fmt.Printf("exiting due to ^C")
>> os.Exit(1)
>> }()
>>
>> That process is entirely independent of whether the function zmq4.Poll
>> returns EINTR or not.
>>
>
> Calling os.Exit will cause the deferred functions to not be called.

Sure, there are many different ways to organize this.  You're right:
you have to be aware that zmq4.Poll can block for a while, and won't
be interrupted if a signal occurs.  That is exactly how every other Go
I/O function works; for example, net.Conn.Read and net.Conn.Write
behave that way.  That's how Go works.

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/CAOyqgcXqj_khPxjHdqMO-xA_LzuhK_X8Rjoa_JVYNOhZ2i%3D4qg%40mail.gmail.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Manlio Perillo]

On Friday, February 28, 2020 at 6:29:56 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Feb 28, 2020 at 9:14 AM Manlio Perillo  > wrote: 
> > 
> > On Friday, February 28, 2020 at 5:36:09 PM UTC+1, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo  
> wrote: 
> >> > 
> > [...] 

>>  Go programs always 
> >> have multiple threads of execution.  Just let a goroutine sit in the 
> >> slow syscall; who cares? 
> >> 
> > 
> > An user running a client program from a terminal may care. 
> > If it takes too long to read data from a remote server, an user expects 
> that ^C will interrupt the program. 
> > 
> > However a solution is to register an atexit handler using a closure to 
> do some cleanup, so probably this is not an issue worth making the Go 
> runtime more complex. 
>
> In Go, a ^C will interrupt a program if you write code like 
>
> c := make(chan os.Signal, 1) 
> signal.Notify(c, syscall.SIGINT) 
> go func() { 
> <-c 
> fmt.Printf("exiting due to ^C") 
> os.Exit(1) 
> }() 
>
> That process is entirely independent of whether the function zmq4.Poll 
> returns EINTR or not. 
>
>
Calling os.Exit will cause the deferred functions to not be called.


Manlio 

-- 
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/8d58caba-d001-43cc-8ec9-3b4f8a3c512e%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Ian Lance Taylor]

On Fri, Feb 28, 2020 at 9:14 AM Manlio Perillo  wrote:
>
> On Friday, February 28, 2020 at 5:36:09 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo  wrote:
>> >
>> > On Friday, February 28, 2020 at 4:57:00 PM UTC+1, Ian Lance Taylor wrote:
>> >>
>> >> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg  wrote:
>> >> >
>> >> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
>> >> >>
>> >> >>
>> >> >> Can you clarify that a bit? Did you change the code to look for EINTR 
>> >> >> errors and then retry the system call?
>> >> >
>> >> >
>> >> > Yes, I did. But as an option that must be enabled by the user.
>> >>
>> >> I don't understand why you're making it an option.  The README
>> >> suggests that you would not want to enable it if you want to handle
>> >> ^C, but in Go the ^C will be delivered on a channel, presumably to a
>> >> separate goroutine.  At that point your program will either exit or do
>> >> some other operation.  If the program doesn't exit, then it's not
>> >> going to want the interrupted system call to fail.  It's going to want
>> >> it to be retried.
>> >>
>> >
>> > But what if the program don't want to call os.Exit from the goroutine 
>> > handling signals, because the function calling a slow syscall want to 
>> > return from the function normally?
>>
>> To me that sounds like a theoretical argument that will never arise in
>> an actual program.  There is a reason to write C programs that way,
>> because it's annoying to have multiple threads of execution, but there
>> is no reason to ever write Go programs that way.  Go programs always
>> have multiple threads of execution.  Just let a goroutine sit in the
>> slow syscall; who cares?
>>
>
> An user running a client program from a terminal may care.
> If it takes too long to read data from a remote server, an user expects that 
> ^C will interrupt the program.
>
> However a solution is to register an atexit handler using a closure to do 
> some cleanup, so probably this is not an issue worth making the Go runtime 
> more complex.

In Go, a ^C will interrupt a program if you write code like

c := make(chan os.Signal, 1)
signal.Notify(c, syscall.SIGINT)
go func() {
<-c
fmt.Printf("exiting due to ^C")
os.Exit(1)
}()

That process is entirely independent of whether the function zmq4.Poll
returns EINTR or not.

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/CAOyqgcWV_c466LwZoiznZpQMMDeB%2B%3DZeh8PM1ov5dQ1u%2ByaExg%40mail.gmail.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Manlio Perillo]

On Friday, February 28, 2020 at 5:36:09 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo  > wrote: 
> > 
> > On Friday, February 28, 2020 at 4:57:00 PM UTC+1, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg  
> wrote: 
> >> > 
> >> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels: 
> >> >> 
> >> >> 
> >> >> Can you clarify that a bit? Did you change the code to look for 
> EINTR errors and then retry the system call? 
> >> > 
> >> > 
> >> > Yes, I did. But as an option that must be enabled by the user. 
> >> 
> >> I don't understand why you're making it an option.  The README 
> >> suggests that you would not want to enable it if you want to handle 
> >> ^C, but in Go the ^C will be delivered on a channel, presumably to a 
> >> separate goroutine.  At that point your program will either exit or do 
> >> some other operation.  If the program doesn't exit, then it's not 
> >> going to want the interrupted system call to fail.  It's going to want 
> >> it to be retried. 
> >> 
> > 
> > But what if the program don't want to call os.Exit from the goroutine 
> handling signals, because the function calling a slow syscall want to 
> return from the function normally? 
>
> To me that sounds like a theoretical argument that will never arise in 
> an actual program.  There is a reason to write C programs that way, 
> because it's annoying to have multiple threads of execution, but there 
> is no reason to ever write Go programs that way.  Go programs always 
> have multiple threads of execution.  Just let a goroutine sit in the 
> slow syscall; who cares? 
>
>
An user running a client program from a terminal may care.
If it takes too long to read data from a remote server, an user expects 
that ^C will interrupt the program.

However a solution is to register an atexit handler using a closure to do 
some cleanup, so probably this is not an issue worth making the Go runtime 
more complex.

Manlio

> 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/16c63d5a-c5dc-41a4-ac44-fd751516c42e%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Ian Lance Taylor]

On Fri, Feb 28, 2020 at 8:13 AM Peter Kleiweg  wrote:
>
> Op vrijdag 28 februari 2020 16:57:00 UTC+1 schreef Ian Lance Taylor:
>>
>> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg  wrote:
>> >
>> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
>> >>
>> >>
>> >> Can you clarify that a bit? Did you change the code to look for EINTR 
>> >> errors and then retry the system call?
>> >
>> >
>> > Yes, I did. But as an option that must be enabled by the user.
>>
>> I don't understand why you're making it an option.  The README
>> suggests that you would not want to enable it if you want to handle
>> ^C, but in Go the ^C will be delivered on a channel, presumably to a
>> separate goroutine.  At that point your program will either exit or do
>> some other operation.  If the program doesn't exit, then it's not
>> going to want the interrupted system call to fail.  It's going to want
>> it to be retried.
>
>
> I leave it to the end user to decide. I was inspired by this: 
> http://250bpm.com/blog:12

That blog post is about programming in C.  Go is different.  In C it
makes sense to let the program decide how to handle EINTR.  In Go, in
my opinion, it does not.


>> (As a minor side note, calls like getsockopt will never return EINTR,
>> it's not necessary to retry them.  But it doesn't hurt.)
>
>
> zmq_getsockopt can return EINTR says the man page.

Odd.  OK.

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/CAOyqgcVQhERQ3eLk9GyquctctF8ZwH0O%3D2fdzD_O1beo1rwySA%40mail.gmail.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Ian Lance Taylor]

On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo  wrote:
>
> On Friday, February 28, 2020 at 4:57:00 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg  wrote:
>> >
>> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
>> >>
>> >>
>> >> Can you clarify that a bit? Did you change the code to look for EINTR 
>> >> errors and then retry the system call?
>> >
>> >
>> > Yes, I did. But as an option that must be enabled by the user.
>>
>> I don't understand why you're making it an option.  The README
>> suggests that you would not want to enable it if you want to handle
>> ^C, but in Go the ^C will be delivered on a channel, presumably to a
>> separate goroutine.  At that point your program will either exit or do
>> some other operation.  If the program doesn't exit, then it's not
>> going to want the interrupted system call to fail.  It's going to want
>> it to be retried.
>>
>
> But what if the program don't want to call os.Exit from the goroutine 
> handling signals, because the function calling a slow syscall want to return 
> from the function normally?

To me that sounds like a theoretical argument that will never arise in
an actual program.  There is a reason to write C programs that way,
because it's annoying to have multiple threads of execution, but there
is no reason to ever write Go programs that way.  Go programs always
have multiple threads of execution.  Just let a goroutine sit in the
slow syscall; who cares?

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/CAOyqgcXMogqrgQpBBku%2BafXRiWeQ1eRONq2qQzXoexUi1-HOSw%40mail.gmail.com.

Re: [go-nuts] Understind how to apply timeout using gouritine

[Jake Montgomery]

Contexts are great. And if your goal is to solve a specific problem, then 
sometimes they may be the best solution. But you implied in your OP that 
you were learning go. And in that case, I would still urge you to 
understand your original channel based code, and why it does not work, and 
how to make it work. 

On Thursday, February 27, 2020 at 2:29:24 PM UTC-5, Juan Mamani wrote:
>
> Hi Brian,
>
> Thanks for your help.  I will try out  to implement your samples in my 
> project.
> But still studying Goroutines and now Context.
>
>
>
> El miércoles, 26 de febrero de 2020, 10:41:26 (UTC-3), Brian Candler 
> escribió:
>>
>> Perhaps slightly clearer:
>> https://play.golang.org/p/DDZxqaEFi-T
>>  
>>
>

-- 
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/985b1bf1-dded-485a-be48-eaa7215b8f3d%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Manlio Perillo]

On Friday, February 28, 2020 at 4:57:00 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg  > wrote: 
> > 
> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels: 
> >> 
> >> 
> >> Can you clarify that a bit? Did you change the code to look for EINTR 
> errors and then retry the system call? 
> > 
> > 
> > Yes, I did. But as an option that must be enabled by the user. 
>
> I don't understand why you're making it an option.  The README 
> suggests that you would not want to enable it if you want to handle 
> ^C, but in Go the ^C will be delivered on a channel, presumably to a 
> separate goroutine.  At that point your program will either exit or do 
> some other operation.  If the program doesn't exit, then it's not 
> going to want the interrupted system call to fail.  It's going to want 
> it to be retried. 
>
>
But what if the program don't want to call os.Exit from the goroutine 
handling signals, because the function calling a slow syscall want to 
return from the function normally?


Manlio

-- 
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/3730faae-c75e-45fc-ae62-0668236fd35b%40googlegroups.com.

Re: [go-nuts] Can't pass -extldflags to golang

[Ian Lance Taylor]

On Fri, Feb 28, 2020 at 5:07 AM Olivia Nelson
 wrote:
>
> I'm trying to use extldflags with golang:
>
> -ldflags '-extld gcc -extldflags="-headerpad 0x500" -w -s'
>
> But go link does not recognize it, it prints the help dialog
>
> # command-line-arguments
> usage: link [options] main.o
>   -B note
> add an ELF NT_GNU_BUILD_ID note when using ELF
>
>   ...
>
>   -extld linker
> use linker when linking in external mode
>   -extldflags flags
> pass flags to external linker
>
> Any ideas?


go build -ldflags '-extld gcc "-extldflags=-headerpad 0x500" -w -s'

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/CAOyqgcWumya1KtYbCVLqnSX6oK0dY1bwKtk3Uqqz_UJjUY7C-A%40mail.gmail.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Peter Kleiweg]

Op vrijdag 28 februari 2020 16:57:00 UTC+1 schreef Ian Lance Taylor:
>
> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg  > wrote: 
> > 
> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels: 
> >> 
> >> 
> >> Can you clarify that a bit? Did you change the code to look for EINTR 
> errors and then retry the system call? 
> > 
> > 
> > Yes, I did. But as an option that must be enabled by the user. 
>
> I don't understand why you're making it an option.  The README 
> suggests that you would not want to enable it if you want to handle 
> ^C, but in Go the ^C will be delivered on a channel, presumably to a 
> separate goroutine.  At that point your program will either exit or do 
> some other operation.  If the program doesn't exit, then it's not 
> going to want the interrupted system call to fail.  It's going to want 
> it to be retried. 
>

I leave it to the end user to decide. I was inspired by this: 
http://250bpm.com/blog:12
 

> (As a minor side note, calls like getsockopt will never return EINTR, 
> it's not necessary to retry them.  But it doesn't hurt.) 
>

zmq_getsockopt can return EINTR says the man page.

And some zmq functions can return EINTR even though their man page doesn't 
mention it.

-- 
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/cbfe48d1-5af8-409a-8d73-87e99f04f1f1%40googlegroups.com.

[go-nuts] Re: Many instances question - shared library

[Luke Mauldin]

I agree that it is not a scalable architecture but unfortunately it is a large 
third party application the business depends on and it cannot be rewritten. 
Option 3 to use grpc is a good idea but unfortunately won’t work either because 
the Go shared library invokes C function calls back into the process that 
loaded it to perform work.
Long term, I am looking at having to rewrite the Go shared library into a 
language that doesn’t have a runtime like C++ or Rust but in the meantime I was 
checking to see if there is anything I can do to lessen the Go runtime overhead 
in this unique situation.

-- 
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/8166ec91-e9e9-4ade-9d89-94512a92fa2e%40googlegroups.com.

[go-nuts] Re: Many instances question - shared library

[Amnon Baron Cohen]

That does not sound like a scalable architecture!

The number of simultaneous user connections the architecture can support is 
limited to the number of processes 
your server can run. The resources required by a process are orders of 
magnitude more than those required for a goroutine.
And the Go runtime adds to that.

Three options:
1) rewrite third party app in Go to run in a single process with a 
goroutine per connection
2) don't use Go for your extension
3) Write a stub extension in C which talks over gRPC to a single Go server 
instance


On Friday, 28 February 2020 15:39:21 UTC, Luke Mauldin wrote:
>
> The multiple instances are required to due to way the 3rd party 
> application works. In brief, it creates a new process for each user 
> connection and then each new process dynamically load the Go shared library 
> to provide C extension points.

-- 
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/4e77316c-5d5f-44d4-968a-ae311ee685d8%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Ian Lance Taylor]

On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg  wrote:
>
> Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
>>
>>
>> Can you clarify that a bit? Did you change the code to look for EINTR errors 
>> and then retry the system call?
>
>
> Yes, I did. But as an option that must be enabled by the user.

I don't understand why you're making it an option.  The README
suggests that you would not want to enable it if you want to handle
^C, but in Go the ^C will be delivered on a channel, presumably to a
separate goroutine.  At that point your program will either exit or do
some other operation.  If the program doesn't exit, then it's not
going to want the interrupted system call to fail.  It's going to want
it to be retried.

(As a minor side note, calls like getsockopt will never return EINTR,
it's not necessary to retry them.  But it doesn't hurt.)

Ian



>> -Original Message-
>> From: Peter Kleiweg
>> Sent: Feb 28, 2020 9:04 AM
>> To: golang-nuts
>> Subject: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 
>> 1.14, no errors with earlier versions
>>
>> Retry after EINTR solved the code lock-up too.
>>
>> Op woensdag 26 februari 2020 12:33:05 UTC+1 schreef Peter Kleiweg:
>>>
>>> With Go version 1.14 I get a lot of errors when I run:
>>>
>>> go test -v github.com/pebbe/zmq4
>>>
>>> I didn't see this with Go 1.13.8 or any earlier version.
>>>
>>> Is this a problem with Go 1.14, or am I doing something wrong and just got 
>>> lucky until now?
>>>
>>> How do I debug this? The errors are different for each run. Below is a 
>>> sample of some errors.
>>> Line numbers are not always accurate, because I inserted some calls to 
>>> test.Log().
>>>
>>> === RUN   TestSocketEvent
>>> TestSocketEvent: socketevent_test.go:73: rep.Bind: interrupted 
>>> system call
>>>
>>>
>>> === RUN   TestMultipleContexts
>>> TestMultipleContexts: zmq4_test.go:131: sock1.Connect: interrupted 
>>> system call
>>>
>>> freeze:
>>> === RUN   TestMultipleContexts
>>> ^CFAIL  github.com/pebbe/zmq4   30.226s
>>>
>>> freeze:
>>> === RUN   TestMultipleContexts
>>> TestMultipleContexts: zmq4_test.go:148: sock1.RecvMessage: expected 
>>>  [tcp://127.0.0.1:9997 tcp://127.0.0.1:9997], got interrupted system 
>>> call []
>>> ^CFAIL  github.com/pebbe/zmq4   21.445s
>>>
>>>
>>>
>>> freeze:
>>> === RUN   TestSecurityCurve
>>> ^CFAIL  github.com/pebbe/zmq4   31.143s
>>>
>>>
>>>
>>> freeze:
>>> === RUN   TestSecurityNull
>>> TestSecurityNull: zmq4_test.go:1753: server.Recv 1: resource 
>>> temporarily unavailable
>>> ^CFAIL  github.com/pebbe/zmq4   44.828s
>>>
>>>
>>> === RUN   TestDisconnectInproc
>>> TestDisconnectInproc: zmq4_test.go:523: Poll: interrupted system 
>>> call
>>> TestDisconnectInproc: zmq4_test.go:623: isSubscribed
>>>
>>> === RUN   TestHwm
>>> TestHwm: zmq4_test.go:823: bind_socket.Bind: interrupted system call
>>> TestHwm: zmq4_test.go:1044: test_inproc_bind_first(0, 0): expected 
>>> 1, got -1
>>>
>>> freeze:
>>> === RUN   TestSecurityPlain
>>> ^CFAIL  github.com/pebbe/zmq4   46.395s
>>>
>>> === RUN   TestPairIpc
>>> TestPairIpc: zmq4_test.go:1124: client.Send SNDMORE|DONTWAIT: 
>>> interrupted system call
>>>
>> --
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f7eb247c-f772-4663-9d0b-5cb07c62e427%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/7659417a-8b56-4a7d-9ae4-91878c7899e1%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/CAOyqgcU95DHMD2N40DvcamKR5K%2BWEj%2BdMzh4RSF6ab%3DnMzzS-Q%40mail.gmail.com.

[go-nuts] Re: Many instances question - shared library

[Luke Mauldin]

The multiple instances are required to due to way the 3rd party application 
works. In brief, it creates a new process for each user connection and then 
each new process dynamically load the Go shared library to provide C extension 
points.

-- 
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/fd96216b-2f15-49ac-af6d-e99f4e4f6ca6%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Peter Kleiweg]

Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
>
>
> Can you clarify that a bit? Did you change the code to look for EINTR 
> errors and then retry the system call?
>

Yes, I did. But as an option that must be enabled by the user.
 

> -Original Message- 
> From: Peter Kleiweg 
> Sent: Feb 28, 2020 9:04 AM 
> To: golang-nuts 
> Subject: [go-nuts] Re: Lot's of test errors in package zmq4 with Go 
> version 1.14, no errors with earlier versions 
>
> Retry after EINTR solved the code lock-up too.
>
> Op woensdag 26 februari 2020 12:33:05 UTC+1 schreef Peter Kleiweg:
>>
>> With Go version 1.14 I get a lot of errors when I run:
>>
>> go test -v github.com/pebbe/zmq4
>>
>> I didn't see this with Go 1.13.8 or any earlier version.
>>
>> Is this a problem with Go 1.14, or am I doing something wrong and just 
>> got lucky until now?
>>
>> How do I debug this? The errors are different for each run. Below is a 
>> sample of some errors.
>> Line numbers are not always accurate, because I inserted some calls to 
>> test.Log().
>>
>> === RUN   TestSocketEvent
>> TestSocketEvent: socketevent_test.go:73: rep.Bind: interrupted 
>> system call
>>
>>
>> === RUN   TestMultipleContexts
>> TestMultipleContexts: zmq4_test.go:131: sock1.Connect: 
>> interrupted system call
>>
>> freeze:
>> === RUN   TestMultipleContexts
>> ^CFAIL  github.com/pebbe/zmq4   30.226s
>>
>> freeze:
>> === RUN   TestMultipleContexts
>> TestMultipleContexts: zmq4_test.go:148: sock1.RecvMessage: 
>> expected  [tcp://127.0.0.1:9997 tcp://127.0.0.1:9997], got 
>> interrupted system call []
>> ^CFAIL  github.com/pebbe/zmq4   21.445s
>>
>>
>>
>> freeze:
>> === RUN   TestSecurityCurve
>> ^CFAIL  github.com/pebbe/zmq4   31.143s
>>
>>
>>
>> freeze:
>> === RUN   TestSecurityNull
>> TestSecurityNull: zmq4_test.go:1753: server.Recv 1: resource 
>> temporarily unavailable
>> ^CFAIL  github.com/pebbe/zmq4   44.828s
>>
>>
>> === RUN   TestDisconnectInproc
>> TestDisconnectInproc: zmq4_test.go:523: Poll: interrupted system 
>> call
>> TestDisconnectInproc: zmq4_test.go:623: isSubscribed
>>
>> === RUN   TestHwm
>> TestHwm: zmq4_test.go:823: bind_socket.Bind: interrupted system 
>> call
>> TestHwm: zmq4_test.go:1044: test_inproc_bind_first(0, 0): 
>> expected 1, got -1
>>
>> freeze:
>> === RUN   TestSecurityPlain
>> ^CFAIL  github.com/pebbe/zmq4   46.395s
>>
>> === RUN   TestPairIpc
>> TestPairIpc: zmq4_test.go:1124: client.Send SNDMORE|DONTWAIT: 
>> interrupted system call
>>
>> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/f7eb247c-f772-4663-9d0b-5cb07c62e427%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/7659417a-8b56-4a7d-9ae4-91878c7899e1%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Robert Engels]

Can you clarify that a bit? Did you change the code to look for EINTR errors and then retry the system call?-Original Message-
From: Peter Kleiweg 
Sent: Feb 28, 2020 9:04 AM
To: golang-nuts 
Subject: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

Retry after EINTR solved the code lock-up too.Op woensdag 26 februari 2020 12:33:05 UTC+1 schreef Peter Kleiweg:With Go version 1.14 I get a lot of errors when I run:    go test -v github.com/pebbe/zmq4I didn't see this with Go 1.13.8 or any earlier version.Is this a problem with Go 1.14, or am I doing something wrong and just got lucky until now?How do I debug this? The errors are different for each run. Below is a sample of some errors.Line numbers are not always accurate, because I inserted some calls to test.Log().    === RUN   TestSocketEvent        TestSocketEvent: socketevent_test.go:73: rep.Bind: interrupted system call    === RUN   TestMultipleContexts        TestMultipleContexts: zmq4_test.go:131: sock1.Connect: interrupted system call    freeze:    === RUN   TestMultipleContexts    ^CFAIL  github.com/pebbe/zmq4   30.226s    freeze:    === RUN   TestMultipleContexts        TestMultipleContexts: zmq4_test.go:148: sock1.RecvMessage: expected  [tcp://127.0.0.1:9997 tcp://127.0.0.1:9997], got interrupted system call []    ^CFAIL  github.com/pebbe/zmq4   21.445s    freeze:    === RUN   TestSecurityCurve    ^CFAIL  github.com/pebbe/zmq4   31.143s    freeze:    === RUN   TestSecurityNull        TestSecurityNull: zmq4_test.go:1753: server.Recv 1: resource temporarily unavailable    ^CFAIL  github.com/pebbe/zmq4   44.828s    === RUN   TestDisconnectInproc        TestDisconnectInproc: zmq4_test.go:523: Poll: interrupted system call        TestDisconnectInproc: zmq4_test.go:623: isSubscribed    === RUN   TestHwm        TestHwm: zmq4_test.go:823: bind_socket.Bind: interrupted system call        TestHwm: zmq4_test.go:1044: test_inproc_bind_first(0, 0): expected 1, got -1    freeze:    === RUN   TestSecurityPlain    ^CFAIL  github.com/pebbe/zmq4   46.395s    === RUN   TestPairIpc        TestPairIpc: zmq4_test.go:1124: client.Send SNDMORE|DONTWAIT: interrupted system call



-- 
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/f7eb247c-f772-4663-9d0b-5cb07c62e427%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/914429447.712.1582902794427%40wamui-lucy.atl.sa.earthlink.net.

[go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Peter Kleiweg]

Retry after EINTR solved the code lock-up too.

Op woensdag 26 februari 2020 12:33:05 UTC+1 schreef Peter Kleiweg:
>
> With Go version 1.14 I get a lot of errors when I run:
>
> go test -v github.com/pebbe/zmq4
>
> I didn't see this with Go 1.13.8 or any earlier version.
>
> Is this a problem with Go 1.14, or am I doing something wrong and just got 
> lucky until now?
>
> How do I debug this? The errors are different for each run. Below is a 
> sample of some errors.
> Line numbers are not always accurate, because I inserted some calls to 
> test.Log().
>
> === RUN   TestSocketEvent
> TestSocketEvent: socketevent_test.go:73: rep.Bind: interrupted 
> system call
>
>
> === RUN   TestMultipleContexts
> TestMultipleContexts: zmq4_test.go:131: sock1.Connect: interrupted 
> system call
>
> freeze:
> === RUN   TestMultipleContexts
> ^CFAIL  github.com/pebbe/zmq4   30.226s
>
> freeze:
> === RUN   TestMultipleContexts
> TestMultipleContexts: zmq4_test.go:148: sock1.RecvMessage: 
> expected  [tcp://127.0.0.1:9997 tcp://127.0.0.1:9997], got 
> interrupted system call []
> ^CFAIL  github.com/pebbe/zmq4   21.445s
>
>
>
> freeze:
> === RUN   TestSecurityCurve
> ^CFAIL  github.com/pebbe/zmq4   31.143s
>
>
>
> freeze:
> === RUN   TestSecurityNull
> TestSecurityNull: zmq4_test.go:1753: server.Recv 1: resource 
> temporarily unavailable
> ^CFAIL  github.com/pebbe/zmq4   44.828s
>
>
> === RUN   TestDisconnectInproc
> TestDisconnectInproc: zmq4_test.go:523: Poll: interrupted system 
> call
> TestDisconnectInproc: zmq4_test.go:623: isSubscribed
>
> === RUN   TestHwm
> TestHwm: zmq4_test.go:823: bind_socket.Bind: interrupted system 
> call
> TestHwm: zmq4_test.go:1044: test_inproc_bind_first(0, 0): expected 
> 1, got -1
>
> freeze:
> === RUN   TestSecurityPlain
> ^CFAIL  github.com/pebbe/zmq4   46.395s
>
> === RUN   TestPairIpc
> TestPairIpc: zmq4_test.go:1124: client.Send SNDMORE|DONTWAIT: 
> interrupted system call
>
>

-- 
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/f7eb247c-f772-4663-9d0b-5cb07c62e427%40googlegroups.com.

[go-nuts] Re: Many instances question - shared library

[Amnon Baron Cohen]

> However, due to the nature of the application, there maybe 100 or 200 
instances

Interesting...
Could you elaborate the nature of the application, and why a single 
instance is not enough... 

-- 
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/f4a19892-ba46-4816-8ae0-9615768ad5b6%40googlegroups.com.

[go-nuts] Many instances question - shared library

[Luke Mauldin]

I have deployed a Go shared library on Linux that exposes C functions as 
extension points for a 3rd party application and is loaded dynamically at 
runtime. The 3rd party application then invokes "C" functions (which are 
backed by Go) and that is all working as expected.  However, due to the 
nature of the application, there maybe 100 or 200 instances of the 3rd 
party application running on the server at any given time and each of those 
is loading its own copy of the Go shared library so I have to "pay the 
penalty" of the Go runtime for each process.  Has anyone else encountered 
this scenario?  Is there anything I can do to reduce this cost?  I have 
already done simple things like setting GOMAXPROCS 1 because generally 
there will only be 1 primary goroutine running in each instance. 
I have looked at tinygo but that seems to be targeting a different use 
case.  Any other recommendations?

Luke

-- 
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/4e921205-67ab-4626-a8fd-441573d4164c%40googlegroups.com.

[go-nuts] Re: Why isn't there strings.reverse("str") function?

[Amnon Baron Cohen]

somebody beat us to it:
https://github.com/torden/go-strutil#reversestr

But for some strange reason, they seem to have made the this a method of a 
StringProc class.
Perhaps they used to code in Java.

On Friday, 28 February 2020 13:07:54 UTC, Himanshu Makkar wrote:
>
> Hi
>
> I think we can create a package to reverse a string and can use it 
> whenever needed.
>
>  reverse.go
>
>
>>

-- 
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/98e8bd00-7722-4513-918b-3b547d395881%40googlegroups.com.

[go-nuts] Go 1.14: how to -linkshared to a library produced by -buildmode=shared?

[misha]

Hello.

I'm trying to build a shared library using `-buildmode=shared` and make a 
binary link to this shared library.

The packages are:

github.com/misha-ridge/splitlib/a (-> c)
github.com/misha-ridge/splitlib/b (-> c)
github.com/misha-ridge/splitlib/c
github.com/misha-ridge/splitlib (-> a, b, c)

I'd like to package `a` and `c` into the shared library, and put `b` and 
`splitlib` into the binary.

I've tried the following:

$ go install -buildmode=shared std
$ go install -buildmode=shared -linkshared  -gcflags='-N -l' ./a

This produced `libgithub.com-misha-ridge-splitlib-a.so` in the current 
directory

Then

$ go build -o main -linkshared  -gcflags='-N -l' .

This produced `main` in the current directory that only links to a shared 
libstd, but not to
the freshly built lib...splitlib-a.so:

$ ldd main
linux-vdso.so.1 (0x7ffea3bfe000)
libstd.so => /usr/local/go/pkg/linux_amd64_dynlink/libstd.so 
(0x7f7ea27f6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7ea2631000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f7ea262c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f7ea260b000)
/lib64/ld-linux-x86-64.so.2 (0x7f7ea4f23000)
$

The shared library does not contain symbols from splitlib/a or splitlib/b:

$ go tool nm libgithub.com-misha-ridge-splitlib-a.so  | grep splitlib
  104cd0 D go.link.abihash.libgithub.com-misha-ridge-splitlib-a.so

Only the final binary does:

$ go tool nm main  | grep splitlib
2180 T github.com/misha-ridge/splitlib/a.SetC
2190 T github.com/misha-ridge/splitlib/b.SetC
2170 T github.com/misha-ridge/splitlib/c.Get
5210 D github.com/misha-ridge/splitlib/c.i
2180 t local.github.com/misha-ridge/splitlib/a.SetC
2190 t local.github.com/misha-ridge/splitlib/b.SetC
2170 t local.github.com/misha-ridge/splitlib/c.Get

Am I missing some step?

The repository with reproducer is at https://github.com/misha-ridge/splitlib

-- 
Best,
Misha.

-- 
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/466454be-a0fe-432d-9f4c-498cd23609d3%40googlegroups.com.

[go-nuts] Re: Why isn't there strings.reverse("str") function?

[Himanshu Makkar]

Hi

I think we can create a package to reverse a string and can use it whenever 
needed.

 reverse.go

package strutil

func Reverse(s string) string {
runes := []rune(s)
for i, j := 0, len(runes)-1; i < j; i, j = i+1, j-1 {
runes[i], runes[j] = runes[j], runes[i]
}
return string(runes)}

come to your original .go programm and import that above reverse.go util package

package main

import(
   "fmt"
   "github.com/himanshu/go_code/strutil" .  // Path of reverse.go file
   )

 func main() {
 fmt.println(strutil.Reverse("Hello World"))
   } 

It dosent take too much memory as well



On Saturday, February 15, 2020 at 10:07:15 PM UTC+5:30, Amarjeet Anand 
wrote:
>
> Hi
>
> I was wondering why isn't there built-in string reverse function. Is it 
> left intentionally because of some reason?
>
> Although strings are immutable in go, there are multiple ways to achieve 
> this pretty easily. But having this function inbuilt will save our time 
> because we need it quite often.
>
>
>

-- 
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/7930beeb-885e-4c41-84bf-124f86d062c7%40googlegroups.com.

[go-nuts] Can't pass -extldflags to golang

[Olivia Nelson]

I'm trying to use extldflags with golang:

-ldflags '-extld gcc -extldflags="-headerpad 0x500" -w -s'

But go link does not recognize it, it prints the help dialog

# command-line-arguments
usage: link [options] main.o
  -B note
add an ELF NT_GNU_BUILD_ID note when using ELF

  ...

  -extld linker
use linker when linking in external mode
  -extldflags flags
pass flags to external linker

Any ideas?

-- 
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/32e64cde-72a9-4079-b218-58e13ca72802%40googlegroups.com.

Re: [go-nuts] Significance of Mon Jan 2 15:04:05 -0700 MST 2006?

[Dan Kortschak]

Rob explained this in a thread a fair while back.

> The choice was made by the output of the date command on my Unix
> machine. I should have realized the format varies with locale. Mea
> culpa. But I can still claim it's easy to remember and well
> documented.

https://groups.google.com/d/msg/golang-nuts/0nQbfyNzk9E/LWbMgpRQNOgJ

On Fri, 2020-02-28 at 09:53 +, Steve Mynott wrote:
> I was just wondering what was the significance, if any, of the magic
> time layout as used by time.Parse()?
> 
> --
> Steve Mynott 
> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
> 
> --
> 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/CANuZA8RVUmbN6aZ256caZjye60ZQLEn-MCjBkio0CEanYSELvQ%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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8764dd43bdab79d5fd053b56410626382aba7b67.camel%40kortschak.io.

Re: [go-nuts] Significance of Mon Jan 2 15:04:05 -0700 MST 2006?

[Jesper Louis Andersen]

Each token is chosen such that it is unique in some way.

So when the parser reaches a token, it can identify it and note the order
in which they occur. This constructs the necessary knowledge we need to
parse a real value.

On Fri, Feb 28, 2020 at 10:53 AM Steve Mynott 
wrote:

> I was just wondering what was the significance, if any, of the magic
> time layout as used by time.Parse()?
>
> --
> Steve Mynott 
> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
>
> --
> 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/CANuZA8RVUmbN6aZ256caZjye60ZQLEn-MCjBkio0CEanYSELvQ%40mail.gmail.com
> .
>


-- 
J.

-- 
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/CAGrdgiX%3DAoWJwiSnLjsvoSV2tGeATLwdOf72qBHUjFD9gYdkHQ%40mail.gmail.com.

Re: [go-nuts] Re: Why isn't there strings.reverse("str") function?

[Amnon Baron Cohen]

That's cool!

Of course we could reverse rune-slice in place, leaving a 7 liner...

func Reverse(s string) string {
   r := []rune(s)
   for i, j := 0, len(r) - 1; i < j; i, j = i +1 , j-1 {
  r[i], r[j] = r[j], r[i]
   }
   return string(r)
}




On Friday, 28 February 2020 08:45:33 UTC, rog wrote:
>
>
>
> On Fri, 28 Feb 2020 at 08:23, Amnon Baron Cohen  > wrote:
>
>> Here is a dumb version, that wastes loads of memory.
>>
>> func reverse(in string) string {
>>out := strings.Builder{}
>>out.Grow(len(in))
>>runes:= make([]rune, 0, len(in))
>>
>>
>>for _, r := range in {
>>   runes = append(runes, r)
>>}
>>
>> You might be interested to know that this operation is built in to Go 
> itself, which means you can do something like this:
>
> func Reverse(s string) string {
> runes := []rune(s)
> rev := make([]rune, 0, len(runes))
> for i := len(runes) - 1; i >= 0; i-- {
> rev = append(rev, runes[i])
> }
> return string(rev)
> }
>
> It's not even *that* much slower (about 60%). It doesn't always preserve 
> the original string length though.
>
>
>
> On Saturday, 15 February 2020 16:37:15 UTC, Amarjeet Anand wrote:
>>
>> Hi
>>
>> I was wondering why isn't there built-in string reverse function. Is it 
>> left intentionally because of some reason?
>>
>> Although strings are immutable in go, there are multiple ways to achieve 
>> this pretty easily. But having this function inbuilt will save our time 
>> because we need it quite often.
>>
>>
>> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/cae39c11-f492-4890-b0ff-332d2e51042b%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/e6239d6d-6dba-4735-902f-2eaf10ffcc38%40googlegroups.com.

[go-nuts] Significance of Mon Jan 2 15:04:05 -0700 MST 2006?

[Steve Mynott]

I was just wondering what was the significance, if any, of the magic
time layout as used by time.Parse()?

-- 
Steve Mynott 
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

-- 
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/CANuZA8RVUmbN6aZ256caZjye60ZQLEn-MCjBkio0CEanYSELvQ%40mail.gmail.com.

Re: [go-nuts] Re: Why isn't there strings.reverse("str") function?

[roger peppe]

On Fri, 28 Feb 2020 at 08:23, Amnon Baron Cohen  wrote:

> Here is a dumb version, that wastes loads of memory.
>
> func reverse(in string) string {
>out := strings.Builder{}
>out.Grow(len(in))
>runes:= make([]rune, 0, len(in))
>
>
>for _, r := range in {
>   runes = append(runes, r)
>}
>
> You might be interested to know that this operation is built in to Go
itself, which means you can do something like this:

func Reverse(s string) string {
runes := []rune(s)
rev := make([]rune, 0, len(runes))
for i := len(runes) - 1; i >= 0; i-- {
rev = append(rev, runes[i])
}
return string(rev)
}

It's not even *that* much slower (about 60%). It doesn't always preserve
the original string length though.



On Saturday, 15 February 2020 16:37:15 UTC, Amarjeet Anand wrote:
>
> Hi
>
> I was wondering why isn't there built-in string reverse function. Is it
> left intentionally because of some reason?
>
> Although strings are immutable in go, there are multiple ways to achieve
> this pretty easily. But having this function inbuilt will save our time
> because we need it quite often.
>
>
> --
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/cae39c11-f492-4890-b0ff-332d2e51042b%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/CAJhgachKABFxMSqU5xy6hQA_%3DF8gTp9qwTnu6UnhaFYrBSUvnQ%40mail.gmail.com.

[go-nuts] Re: Why isn't there strings.reverse("str") function?

[Amnon Baron Cohen]

Here is a dumb version, that wastes loads of memory.

func reverse(in string) string {
   out := strings.Builder{}
   out.Grow(len(in))
   runes:= make([]rune, 0, len(in))


   for _, r := range in {
  runes = append(runes, r)
   }
   for i := len(runes) -1; i >= 0; i-- {
  out.WriteRune(runes[i])
   }
   return out.String()
}




On Saturday, 15 February 2020 16:37:15 UTC, Amarjeet Anand wrote:
>
> Hi
>
> I was wondering why isn't there built-in string reverse function. Is it 
> left intentionally because of some reason?
>
> Although strings are immutable in go, there are multiple ways to achieve 
> this pretty easily. But having this function inbuilt will save our time 
> because we need it quite often.
>
>
>

-- 
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/cae39c11-f492-4890-b0ff-332d2e51042b%40googlegroups.com.