[go-nuts] Loading Go plugin from Go shared library ends up with `fatal error: runtime: no plugin module data`

[Karthik Krishnamurthy]

Hello,

This is probably an unusual situation, but I am working on a product that 
has the following chain of invocation.

C (native shared library libfoo.so) -> Go (c-shared libbar.so)

So basically, a native C shared library invokes a -buildmode=c-shared type 
Go shared library. This interaction works just fine.

However, we are augmenting libbar.so (Go shared library) to invoke a 
Go-style plugin (libplugin.so) using Go's plugin package. The very first 
attempt of this, failed like this:

fatal error: runtime: no plugin module data


goroutine 17 [running, locked to thread]:
runtime.throw(0xf72b5cc4, 0x1e)
/usr/local/go/src/runtime/panic.go:774 +0x70 fp=0xc64d1b48 sp=0xc64d1b34 
pc=0xf71bfdd0
plugin.lastmoduleinit(0xc648e5e0, 0x1001, 0x1001, 0xc64823e8, 0x95b9588)
/usr/local/go/src/runtime/plugin.go:20 +0xa50 fp=0xc64d1bd4 sp=
0xc64d1b48 pc=0xf71c1420
plugin.open(0xc64a60c0, 0x26, 0x29, 0xc64a6060, 0x2a)
/usr/local/go/src/plugin/plugin_dlopen.go:77 +0x388 fp=0xc64d1d2c sp=
0xc64d1bd4 pc=0xf7275ad8
plugin.Open(...)
/usr/local/go/src/plugin/plugin.go:32
zero/base/interfaces.glob..func1(0xc64a60c0, 0x29, 0xf72b2610, 0x11, 0x29, 
0x0, 0xf719e2e5, 0xf71d958c)
/app/base/interfaces/plugin.go:12 +0x2e fp=0xc64d1d68 sp=0xc64d1d2c pc=
0xf7276cbe
zero/base.glob..func4(0xf7759c60, 0x21, 0xf7357f80, 0xc64823e0, 0xc64a8445, 
0x5, 0xf, 0xe, 0xd, 0xd)
/app/base/zl_helper.go:28 +0xb4 fp=0xc64d1d9c sp=0xc64d1d68 pc=
0xf72ac554
main.glob..func10(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 0x1b, 
0x15, 0xc648e5c0, 0x5, ...)
/app/dec/dec.go:328 +0x7a fp=0xc64d1dd8 sp=0xc64d1d9c pc=0xf72aeb0a
main.glob..func11(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 0x1b, 
0x15, 0xc6496040, 0x5, ...)
/app/dec/dec.go:368 +0xa3 fp=0xc64d1e34 sp=0xc64d1dd8 pc=0xf72aee13
main.Decorate(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 0x1b, 0x15
, 0xc6436000)
/app/dec/dec.go:98 +0x1f3 fp=0xc64d1eac sp=0xc64d1e34 pc=0xf72ad0b3
main._cgoexpwrap_079f3b2ec7da_Decorate(0xffa1e800, 0x2, 0x2, 0xf7759c60, 
0x21, 0xf775ac60, 0x1b, 0x15, 0x0)
_cgo_gotypes.go:79 +0x95 fp=0xc64d1ef4 sp=0xc64d1eac pc=0xf72ace15
runtime.call64(0x0, 0xffa1e72c, 0xffa1e79c, 0x24, 0x0)
/usr/local/go/src/runtime/asm_386.s:571 +0x31 fp=0xc64d1f38 sp=
0xc64d1ef4 pc=0xf71e9ad1
runtime.cgocallbackg1(0x0)
/usr/local/go/src/runtime/cgocall.go:314 +0x162 fp=0xc64d1fb0 sp=
0xc64d1f38 pc=0xf71966f2
runtime.cgocallbackg(0x0)
/usr/local/go/src/runtime/cgocall.go:191 +0x9d fp=0xc64d1fe0 sp=
0xc64d1fb0 pc=0xf719650d
runtime.cgocallback_gofunc(0x0, 0x0, 0x0, 0x0)
/usr/local/go/src/runtime/asm_386.s:810 +0x79 fp=0xc64d1ff0 sp=
0xc64d1fe0 pc=0xf71eab79
runtime.goexit()
/usr/local/go/src/runtime/asm_386.s:1325 +0x1 fp=0xc64d1ff4 sp=
0xc64d1ff0 pc=0xf71eb081
Aborted


What is the error indicative of?

Is invoking go plugin from go shared library supported?

I know Go plugins have a few restrictions. I have verified that all the 
above libraries are built on the same machine with the same gcc/go toolkit.

-- 
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/0a9f699a-74ed-4c5b-9b3a-f4cd2e15f27b%40googlegroups.com.

Re: [go-nuts] Panicking in public API ?

[Dan Kortschak]

Speaking as someone who is probably to blame for a significant
proliferation of public facing panics, that example is probably not a
good place for it.

There are uses in the standard library of public facing panics, but
they generally fall into the categories of simulating the type system
(in reflect), or compiler-time known things that should never fail (in
text/template and html/template where the commonly used functions
return an error and a conversion "must" function convert a non-nil
error to a panic.

On Mon, 2020-01-06 at 23:10 -0800, Tay wrote:
> Hi,
> 
> Just a quick question. I know it's well accepted that panics leaking
> to the 
> public API of a library is generally a no-go.
> 
> Yet, are there any exception to the rule?
> 
> For instance, I have a library that instantiates some database
> prepared 
> statements (so, the majority of the elements are instantiated and
> used in 
> the main function). I would like to panic instead of returning an
> error 
> because, if db.Prepare(q) returns an error, there is no point in 
> continuing, the error is barely recoverable. Besides, it will allow
> for a 
> better looking API so to speak.
> 
> Any comments?
> 

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

Re: [go-nuts] Panicking in public API ?

['Axel Wagner' via golang-nuts]

On Tue, Jan 7, 2020 at 8:10 AM Tay  wrote:

> Hi,
>
> Just a quick question. I know it's well accepted that panics leaking to
> the public API of a library is generally a no-go.
>

Not *that* well accepted :) I tend to disagree. But maybe I'm simply in a
vanishingly small minority.

Yet, are there any exception to the rule?
>

The standard library offers a lot of exceptions. The reflect and the
math/big packages, for example, use panics explicitly to alert to bugs.
Going further, the vast majority of methods which uses pointer-receivers
"leaks panics" if called on a nil-pointer, or any function which calls
methods on an interface, if that's nil - which means almost all packages
panic in at least *some* circumstances.

Personally, I consider panics "run-time type-errors". That is, they
indicate a bug that couldn't be caught statically by the type-system - so
the program shouldn't have compiled in the first place and crashing it is
the right choice. Dereferencing a nil-pointer or indexing out-of-bounds
fall into that category. So does using reflect to do otherwise invalid
operations (which is why reflect panics). IMO, a straight-out rejection of
panics doesn't make sense, unless you assume your type-system is perfect
and so there are no bug-free programs.

Another way to look at it, is that a panic in general dumps a stack-trace,
while an error is being presented to the human using the resulting
software. And that stack-traces in general are not actionable to the user
of a software, but only its developer - while error message don't contain
the necessary details to debug a program, but can (should!) provide
actionable advise to its user. Thus, panics are the right tool to use when
reporting an issue that requires programmer attention and errors are the
right tool when reporting an issue that requires user-attention (or, of
course, can be handled programmatically).¹

For instance, I have a library that instantiates some database prepared
> statements (so, the majority of the elements are instantiated and used in
> the main function). I would like to panic instead of returning an error
> because, if db.Prepare(q) returns an error, there is no point in
> continuing, the error is barely recoverable. Besides, it will allow for a
> better looking API so to speak.
>

A prepared statement could fail to compile for reasons that are not bugs,
as AFAIK they are compiled in the database-server. So if that's
unavailable, or there is a version-incompatibility, or some resource is
exhausted… statement-preparation could fail and just indicate a normal
error, just like os.Open or the like. In other words, an error in preparing
a statement could originate outside the program itself.

So, based on my own perspective above, I wouldn't panic in this case. Note
that whether or not that error is recoverable (in your opinion) is
immaterial for that. Even if the program immediately stops - if it does so
with a panic and a stack-trace, a user will just throw up their hands in
frustration, but if it provides an actionable error-message, they can fix
that issue and retry.

Of course, the fun part about compiling a statement is that it can *also*
fail due to bugs, by the way. So, the advanced version of these rules would
attempt to distinguish between the two and panic e.g. on a syntax-error in
a string-literal (to make it easier to debug and harder to accidentally put
into production) and return an error in external error conditions. I have
some code that does such checks.

Axel

[1] Corollary, of course, is "don't put stack-traces into your errors" :)


> Any comments?
>
> --
> 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/25204eae-8550-4a78-94a3-6a63e9906f20%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/CAEkBMfHxO4W7KHXCK-P8tZZz2g2yctL4HcoU%3D3ZfDY%2B-E5KRdg%40mail.gmail.com.

[go-nuts] Panicking in public API ?

[Tamás Gulácsi]

Panic is for unrecoverable errors. If that query is provided by the user, then 
return an error.
If it is part of your library, and cannot be wrong, then panic.

-- 
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/14013c2c-826c-4a44-a75b-134ef143b4c9%40googlegroups.com.

[go-nuts] Panicking in public API ?

[Tay]

Hi,

Just a quick question. I know it's well accepted that panics leaking to the 
public API of a library is generally a no-go.

Yet, are there any exception to the rule?

For instance, I have a library that instantiates some database prepared 
statements (so, the majority of the elements are instantiated and used in 
the main function). I would like to panic instead of returning an error 
because, if db.Prepare(q) returns an error, there is no point in 
continuing, the error is barely recoverable. Besides, it will allow for a 
better looking API so to speak.

Any comments?

-- 
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/25204eae-8550-4a78-94a3-6a63e9906f20%40googlegroups.com.

[go-nuts] How to get the index of a slice of type string

[nks]

How to get the index of a slice of type string like in this example, I want 
to test if the index equals to 3 in slice b and print ok.


a:=[int]string("hi","holla","salut") b=append(a) b =append(b,"c") for _, 
count:= range b{ if b[]=3 { fmt.Println("ok") };
Enter code here...


-- 
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/8cad2c9e-b4ed-4091-bb85-e894c0f573e5%40googlegroups.com.

Re: [go-nuts] Query on Interfaces

[Prabhu Chawandi]

Thank you, it is clear now.

On Tue, Jan 7, 2020 at 11:10 AM Ian Lance Taylor  wrote:

> On Mon, Jan 6, 2020 at 9:18 PM Prabhu Chawandi 
> wrote:
> >
> >   I was reading this article @
> https://blog.golang.org/laws-of-reflection
> >
> > Excerpt:
> >
> > One important detail is that the pair inside an interface always has the
> form (value, concrete type) and cannot have the form (value, interface
> type). Interfaces do not hold interface values.
> >
> > I could not understand it clearly, Can through some clarity with an
> example?
> >
> > I tried this and did not give any error.
> >
> > @ https://play.golang.org/p/Q5jRWp6MF7c
>
> Interfaces do not hold interface values.
>
> What this means is that when you write "a = b" where a and b are both
> of interface type, then the value that is in b will be copied to a.  a
> will wind up with the dynamic type and dynamic value that were
> originally in b.  The dynamic type of a will not become the type of b;
> it will become the dynamic type of the value stored in b.
>
> Ian
>


-- 
Cheers
p.

-- 
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/CAN9r%3DsyFvWiYGf0m%2BaT6By4VhO_cGH0-V0vs%3DaffCFHfLm1ZtA%40mail.gmail.com.

Re: [go-nuts] Query on Interfaces

[Ian Lance Taylor]

On Mon, Jan 6, 2020 at 9:18 PM Prabhu Chawandi  wrote:
>
>   I was reading this article @ https://blog.golang.org/laws-of-reflection
>
> Excerpt:
>
> One important detail is that the pair inside an interface always has the form 
> (value, concrete type) and cannot have the form (value, interface type). 
> Interfaces do not hold interface values.
>
> I could not understand it clearly, Can through some clarity with an example?
>
> I tried this and did not give any error.
>
> @ https://play.golang.org/p/Q5jRWp6MF7c

Interfaces do not hold interface values.

What this means is that when you write "a = b" where a and b are both
of interface type, then the value that is in b will be copied to a.  a
will wind up with the dynamic type and dynamic value that were
originally in b.  The dynamic type of a will not become the type of b;
it will become the dynamic type of the value stored in b.

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/CAOyqgcXNqQ6Fa%2BomP0x35ty%2BLB3UZcq%2B%3DFzwzhYwrTzp-aX0Zg%40mail.gmail.com.

Re: [go-nuts] channel synchronous, how to assure happens before ??

[hao dong]

Thank you for your reply, I agree there should be a memory barrier for the 
channel, for it is different from the other assignment statements and not a 
write operation. Have you got some readings talk about this?

On Tuesday, January 7, 2020 at 10:17:43 AM UTC+8, Kurtis Rader wrote:
>
> On Mon, Jan 6, 2020 at 5:47 PM hao dong > 
> wrote:
>
>> thanks for your reply. Could you guide me any readings or source code 
>> about channel of happens before.
>>
>
> I think you have misunderstood this text in the https://golang.org/ref/mem 
> document you linked to:
>
> Within a single goroutine, reads and writes must behave as if they 
>> executed in the order specified by the program. That is, compilers and 
>> processors may reorder the reads and writes executed within a single 
>> goroutine only when the reordering does not change the behavior within that 
>> goroutine as defined by the language specification. Because of this 
>> reordering, the execution order observed by one goroutine may differ from 
>> the order perceived by another.
>
>  
> The send on the channel is not a "write" operation in the sense meant by 
> the above text. Nor is the receive on the channel a "read" operation. That 
> paragraph is talking about reads and writes of memory in units (bytes, 
> words, etc.) supported by the CPU. Also, notice the "only when the 
> reordering does not change the behavior" portion of the above text. If the 
> compiler did the assignment after the send on the channel that would change 
> the behavior of the program. Channel ops are what are known as memory 
> barriers, and thus don't allow ops before or after the channel op to be 
> reordered before or after the op.
>
> -- 
> 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/37c57f74-f736-4b12-bbb4-ddbac172ec74%40googlegroups.com.

[go-nuts] Query on Interfaces

[Prabhu Chawandi]

Hello,

  I was reading this article @ https://blog.golang.org/laws-of-reflection

Excerpt:

One important detail is that the pair inside an interface always has the
form (value, concrete type) and cannot have the form (value, interface
type). Interfaces do not hold interface values.

I could not understand it clearly, Can through some clarity with an example?

I tried this and did not give any error.

@ https://play.golang.org/p/Q5jRWp6MF7c


-- 
Cheers
p.

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

Re: [go-nuts] channel synchronous, how to assure happens before ??

[Kurtis Rader]

On Mon, Jan 6, 2020 at 5:47 PM hao dong  wrote:

> thanks for your reply. Could you guide me any readings or source code
> about channel of happens before.
>

I think you have misunderstood this text in the https://golang.org/ref/mem
document you linked to:

Within a single goroutine, reads and writes must behave as if they executed
> in the order specified by the program. That is, compilers and processors
> may reorder the reads and writes executed within a single goroutine only
> when the reordering does not change the behavior within that goroutine as
> defined by the language specification. Because of this reordering, the
> execution order observed by one goroutine may differ from the order
> perceived by another.


The send on the channel is not a "write" operation in the sense meant by
the above text. Nor is the receive on the channel a "read" operation. That
paragraph is talking about reads and writes of memory in units (bytes,
words, etc.) supported by the CPU. Also, notice the "only when the
reordering does not change the behavior" portion of the above text. If the
compiler did the assignment after the send on the channel that would change
the behavior of the program. Channel ops are what are known as memory
barriers, and thus don't allow ops before or after the channel op to be
reordered before or after the op.

-- 
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%3DD_3tiYtAEBiNypQZjcZQD3NH1XBJ8C%3DP8D9buYxdZfdqA%40mail.gmail.com.

Re: [go-nuts] channel synchronous, how to assure happens before ??

[hao dong]

thanks for your reply. Could you guide me any readings or source code about 
channel of happens before.

On Tuesday, January 7, 2020 at 3:02:30 AM UTC+8, Ian Lance Taylor wrote:
>
> On Mon, Jan 6, 2020 at 10:55 AM hao dong > 
> wrote: 
> > 
> > After reading blog post : https://golang.org/ref/mem 
> > 
> > I got one question, in the code below: 
> > 
> > 
> > var c = make(chan int, 10) 
> > var a string 
> > 
> > func f() { 
> > a = "hello, world" 
> > c <- 0 
> > } 
> > 
> > func main() { 
> > go f() 
> > <-c 
> > print(a) 
> > } 
> > 
> > 
> > How can the complier knows that  a = "hello, world" happens  c <-0. Or 
> could it possible that  c <-0 happens first, a = "hello, world" happens 
> second ?? 
>
> The compiler ensures that the assignment to a happens before the send 
> operation on c. 
>
> If that doesn't answer your question, can you explain in more detail? 
>
> 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/5283097c-e526-4e01-8174-449a8cf4e6e0%40googlegroups.com.

Re: [go-nuts] doubt about reflect.Type.String and empty interface

[Manlio Perillo]

On Sun, Jan 5, 2020 at 5:29 PM Ian Lance Taylor  wrote:
>
> On Sun, Jan 5, 2020 at 8:23 AM Manlio Perillo  
> wrote:
> >
>> [...]
> > I decided to run a simple test
> > https://play.golang.org/p/QAX92NQDqO4.
> >
> > [...]
> >
> > The question is: why reflect.Type.String() returns `` instead of  
> > `interface{}` ?
> > Is the example printing the static or the dynamic type?
>
> https://blog.golang.org/laws-of-reflection
>
> The reflect package takes value of type interface{}, so passing a
> value of type interface{} and passing a value of type *interface{}
> acts differently.
>
> Ian

Right, thanks.  I was probably assuming TypeOf to be a generic function.

I wrote another test https://play.golang.org/p/hoTAnijCfg1.
Now it is clear why the first entry can only print nil for the type
and  for the value.

However printf %v verb prints nil for both an empty interface and an
interface with a dynamic value of nil:
https://play.golang.org/p/m_WfR2SPWQ3
Can this cause confusion?

Thanks
Manlio Perillo

-- 
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/CAAToxAGxQ_yXTUK-Jvw1eK8zwGnwXUXk7rCtB89XsCKNc_mpKg%40mail.gmail.com.

Re: [go-nuts] RecvMsgUDP / SendMsgUDP

[Ian Lance Taylor]

On Mon, Jan 6, 2020 at 12:46 PM John Dreystadt  wrote:
>
> I noticed that the documentation for net.RecvMesgUDP and net.SendMesgUDP 
> seemed a bit odd because it referred to “out of band” for some of the 
> parameters being passed and some of the return values. This caused me to look 
> closely at these two functions and here are the results of my research. 
> First, the documentation uses “out of band” when most other documentation, 
> such as the Linux docs for recvmsg(2), use either “control messages” or 
> “ancillary information” for the same fields. This may confuse newcomers to 
> these functions as “out of band” looks like a reference to the TCP concept of 
> “out of band” which is specific to TCP and not present in UDP. Second, the 
> “out of band” fields in question are not useful unless certain socket options 
> are set which cannot be done using the functions available in the “net” 
> package. Third, the “golang.org/x/net” package provides access to most of the 
> socket options in question but not all (the socket option IPPROTO_IP, 
> IP_PKTINFO is not available). There are functions in 
> “golang.org/x/net/internal/socket” for both setting arbitrary socket options 
> and calling recvmsg/sendmsg (still assuming Linux here but Windows just has 
> different names). These cannot be called by user programs because they are in 
> an “internal” package. Fourth and last, I don’t see any way to determine if a 
> read of a TCP socket (not UDP this time) has returned out of band 
> information. In C, I would use recvmsg and check the returned flags for the 
> bit MSG_OOB but there is no RecvMesgTCP.
>
> I have a proposal for changes but I wanted to see if anyone disagreed with 
> the above. I would be especially interested in anyone using these two 
> functions today.

I guess you're talking about net.UDPConn.WriteMsgUDP and
net.UDPConn.ReadMsgUDP.  I agree that on Unix systems that "out of
band" data is normally called "ancillary data," and we should change
the net package docs.

User programs can set arbitrary socket options by using
net.UDPConn.SyscallConn to get a syscall.RawConn and calling the
Control method.  But I agree that that procedure needs to be better
documented somewhere.

I'm kind of surprised that there is no way to handle TCP out-of-band
data but I admit that I don't see one.

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/CAOyqgcVT9PRzqq7X8L%2BLzQPD-2YBigN4OEcdHZeoOzWbhH7CRQ%40mail.gmail.com.

[go-nuts] RecvMsgUDP / SendMsgUDP

[John Dreystadt]

I noticed that the documentation for net.RecvMesgUDP and net.SendMesgUDP seemed 
a bit odd because it referred to “out of band” for some of the parameters being 
passed and some of the return values. This caused me to look closely at these 
two functions and here are the results of my research. First, the documentation 
uses “out of band” when most other documentation, such as the Linux docs for 
recvmsg(2), use either “control messages” or “ancillary information” for the 
same fields. This may confuse newcomers to these functions as “out of band” 
looks like a reference to the TCP concept of “out of band” which is specific to 
TCP and not present in UDP. Second, the “out of band” fields in question are 
not useful unless certain socket options are set which cannot be done using the 
functions available in the “net” package. Third, the “golang.org/x/net” package 
provides access to most of the socket options in question but not all (the 
socket option IPPROTO_IP, IP_PKTINFO is not available). There are functions in 
“golang.org/x/net/internal/socket” for both setting arbitrary socket options 
and calling recvmsg/sendmsg (still assuming Linux here but Windows just has 
different names). These cannot be called by user programs because they are in 
an “internal” package. Fourth and last, I don’t see any way to determine if a 
read of a TCP socket (not UDP this time) has returned out of band information. 
In C, I would use recvmsg and check the returned flags for the bit MSG_OOB but 
there is no RecvMesgTCP.

I have a proposal for changes but I wanted to see if anyone disagreed with the 
above. I would be especially interested in anyone using these two functions 
today.

John Dreystadt 
 

-- 
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/5fce6cc7-8129-42a2-ade7-26c8b2d609f7%40googlegroups.com.

Re: [go-nuts] channel synchronous, how to assure happens before ??

[Ian Lance Taylor]

On Mon, Jan 6, 2020 at 10:55 AM hao dong  wrote:
>
> After reading blog post : https://golang.org/ref/mem
>
> I got one question, in the code below:
>
>
> var c = make(chan int, 10)
> var a string
>
> func f() {
> a = "hello, world"
> c <- 0
> }
>
> func main() {
> go f()
> <-c
> print(a)
> }
>
>
> How can the complier knows that  a = "hello, world" happens  c <-0. Or could 
> it possible that  c <-0 happens first, a = "hello, world" happens second ??

The compiler ensures that the assignment to a happens before the send
operation on c.

If that doesn't answer your question, can you explain in more detail?

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

[go-nuts] channel synchronous, how to assure happens before ??

[hao dong]

After reading blog post : https://golang.org/ref/mem

I got one question, in the code below:


var c = make(chan int, 10)
var a string

func f() {
a = "hello, world"
c <- 0
}

func main() {
go f()
<-c
print(a)
}


How can the complier knows that  a = "hello, world" happens  c <-0. Or 
could it possible that  c <-0 happens first, a = "hello, world" happens 
second ??

-- 
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/2257b529-ce46-4996-9497-c3190975c0c9%40googlegroups.com.

[go-nuts] Re: modules exclude version and above

[Jérôme LAFORGE]

I use this version:
go version go1.13.5 linux/amd64

-- 
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/d8e502c5-80cf-4aab-943c-0216b15afa33%40googlegroups.com.

[go-nuts] Re: modules exclude version and above

[Jérôme LAFORGE]

Thx for your support.

> Could you provide explicit steps (ideally a `go.mod` file and a 
corresponding `.go` source file, and the version of the Go toolchain you 
are using) to reproduce the problem?
With this go.mod https://play.golang.org/p/PeSbMFMAsHf & with go get -u 
./... the version stills on v1 branch.

With this go.mod https://play.golang.org/p/jAw0ENF1Y6V (without exclude on 
all versions in v2 branch) & with go get -u ./... I got this error:
go: downloading github.com/nicksnyder/go-i18n v2.0.3+incompatible
go: extracting github.com/nicksnyder/go-i18n v2.0.3+incompatible
build xxx: cannot load github.com/nicksnyder/go-i18n/i18n: module 
github.com/nicksnyder/go-i18n@latest found (v2.0.3+incompatible), but does 
not contain package github.com/nicksnyder/go-i18n/i18n

And the go.mod has changed:
--- a/src/xxx/go.mod
+++ b/src/xxx/go.mod
@@ -27,7 +27,7 @@ require (
github.com/nats-io/jwt v0.3.2 // indirect
github.com/nats-io/nats-server/v2 v2.1.0 // indirect
github.com/nats-io/nats.go v1.9.1
*-   github.com/nicksnyder/go-i18n v1.10.1*
*+   github.com/nicksnyder/go-i18n v2.0.3+incompatible*
github.com/pelletier/go-toml v1.6.0 // indirect
github.com/prometheus/client_golang v1.3.0
github.com/rogpeppe/go-charset v0.0.0-20190617161244-0dc95cdf6f31


For the source files, I can't provide it.

Thx for the links, I will check 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/3dc1f29e-1433-4caf-af0a-dda6398cafc0%40googlegroups.com.

[go-nuts] Re: modules exclude version and above

['Bryan C. Mills' via golang-nuts]

Could you provide explicit steps (ideally a `go.mod` file and a 
corresponding `.go` source file, and the version of the Go toolchain you 
are using) to reproduce the problem?

All three of those `v2` versions appear to have `go.mod` files, so the `go` 
command should not allow them to be used as `+incomptable` versions at all, 
let alone use them by default.
(See https://golang.org/doc/go1.13#version-validation.)

Moreover, because the latest `v1` release of that module includes a go.mod 
 file, as of Go 
1.14 beta 1 the `go` command should ignore `+incompatible` versions when 
resolving upgrades to that module.
(See https://tip.golang.org/doc/go1.14#incompatible-versions.)


On Friday, January 3, 2020 at 3:49:27 PM UTC-5, Jérôme LAFORGE wrote:
>
> Hello,
>
> Does it exist a way to exclude modules' version and above  ?
>
> Currently I have to do this (in order to not use v2) in my go.mod:
>
> exclude (
> github.com/nicksnyder/go-i18n v2.0.1+incompatible
> github.com/nicksnyder/go-i18n v2.0.2+incompatible
> github.com/nicksnyder/go-i18n v2.0.3+incompatible
> )
>
> Many thx
> Jérôme
>

-- 
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/c195e5b0-866a-4b42-af8d-15b7eb52db5a%40googlegroups.com.

Re: [go-nuts] Publishing and using go module from tarball?

['Bryan C. Mills' via golang-nuts]

See also the golang.org/x/mod/zip 
 package.

On Monday, January 6, 2020 at 10:02:25 AM UTC-5, Amnon Baron Cohen wrote:
>
> > Go modules tooling does not seem to support http at
> > all and as for the https I did not find any way to allow use of 
> self-signed
> > certificate...
>
> In Go 1.14 (available as in beta) you can set the GOINSECURE env var to 
> allow http download.
> https://tip.golang.org/cmd/go/#hdr-Environment_variables
>
>
>>

-- 
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/af46c004-c8e1-4491-ba5f-27e1ad1f217d%40googlegroups.com.

Re: [go-nuts] Publishing and using go module from tarball?

[Amnon Baron Cohen]

> Go modules tooling does not seem to support http at
> all and as for the https I did not find any way to allow use of 
self-signed
> certificate...

In Go 1.14 (available as in beta) you can set the GOINSECURE env var to 
allow http download.
https://tip.golang.org/cmd/go/#hdr-Environment_variables


>

-- 
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/457d73e2-a353-47fe-850f-2d8a88b819b6%40googlegroups.com.

Re: [go-nuts] Publishing and using go module from tarball?

[Amnon Baron Cohen]

In Go 1.14 (available as in beta) you can set the GOINSECURE env var to 
allow http download.
https://tip.golang.org/cmd/go/#hdr-Environment_variables

On Sunday, 5 January 2020 17:34:50 UTC, volf...@gmail.com wrote:
>
>
>
> On Sunday, January 5, 2020 at 11:02:52 AM UTC, Amnon Baron Cohen wrote:
> > If you are happy publishing a zip archive rather than a tarball,
> > then you can server the module download protocol directly.
> > See https://research.swtch.com/vgo-module#download_protocol
>
> That definitely looks interesting and I will try to find some time to look 
> into it
> deeper, however testing it locally seems much more difficult then it really
> should have been. Go modules tooling does not seem to support http at
> all and as for the https I did not find any way to allow use of self-signed
> certificate...
>
> But still, it looks like it might be possible so thanks again, I will try 
> to
> twist it to work for my use-case.
>
> Thanks :)
>
> W.
>

-- 
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/aedbf622-b1e1-4c7e-8c94-07305734422a%40googlegroups.com.

Re: [go-nuts] Re: distributed runtime

[Robert Engels]

I think you want to use “nats streaming”. It does throttling via ACKs. 

> On Jan 6, 2020, at 7:35 AM, Jason E. Aten  wrote:
> 
> 
>>> On Mon, Jan 6, 2020 at 6:24 AM Robert Engels  wrote:
>>> I’m pretty sure Nats.io has all of the same delivery guarantees as 
>>> rabbitmq. What design is not accommodated by mats?
>>  
>> Any design that needs flow control is not accommodated by Nats.io. I've used 
>> Nats extensively and consider it fundamentally flawed for data conveyance. 
>> It is only suitable for very light weight control messages that do not need 
>> to be delivered; where the application logic handles the retries instead of 
>> TCP.  Push any kind of data through Nats, and its lack of flow control means 
>> it will drop most all of your data on the floor.

-- 
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/FB78E62B-9310-4462-ADCA-59A184218DDB%40ix.netcom.com.

Re: [go-nuts] Re: distributed runtime

[Jason E. Aten]

On Mon, Jan 6, 2020 at 6:24 AM Robert Engels  wrote:

> I’m pretty sure Nats.io has all of the same delivery guarantees as
> rabbitmq. What design is not accommodated by mats?
>

Any design that needs flow control is not accommodated by Nats.io. I've
used Nats extensively and consider it fundamentally flawed for data
conveyance. It is only suitable for very light weight control messages that
do not need to be delivered; where the application logic handles the
retries instead of TCP.  Push any kind of data through Nats, and its lack
of flow control means it will drop most all of your data on the floor.

>

-- 
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/CAPNEFAZcYLO%3DVkkeC4TzG0Tv8JxrrHoopRnV-mjTCOCnXAZO1Q%40mail.gmail.com.

Re: [go-nuts] Re: distributed runtime

[Robert Engels]

I’m pretty sure Nats.io has all of the same delivery guarantees as rabbitmq. 
What design is not accommodated by mats?

> On Jan 6, 2020, at 4:56 AM, ffm2...@web.de wrote:
> 
> 
> 
>> 
>> However, if you want to apply supervision for distributed Go channels you 
>> have to change from channels to actors - at least behind the scenes of the 
>> distributed channels. AFAIK, no one has done something like that for 
>> anything writen in Go. Nats is very reliable, but does not provide 
>> guaranteed "all or nothing" delivery.
> 
> Coming to think of it you could make use of Rabbitmq as the distributed 
> channel provider. It is written in Erlang and fulfills this "all or nothing" 
> requirement. Bindings for Go already exist: 
> https://godoc.org/github.com/streadway/amqp
> -- 
> 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/52a565de-6c95-4a28-b8fd-1fc5bb6b1fb6%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/F4B07F85-D655-468A-974F-FCC3A6BD621B%40ix.netcom.com.

[go-nuts] Re: distributed runtime

[ffm2002]

>
> However, if you want to apply supervision for distributed Go channels you 
> have to change from channels to actors - at least behind the scenes of the 
> distributed channels. AFAIK, no one has done something like that for 
> anything writen in Go. Nats is very reliable, but does not provide 
> guaranteed "all or nothing" delivery.
>

Coming to think of it you could make use of Rabbitmq as the distributed 
channel provider. It is written in Erlang and fulfills this "all or 
nothing" requirement. Bindings for Go already exist: 
https://godoc.org/github.com/streadway/amqp

-- 
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/52a565de-6c95-4a28-b8fd-1fc5bb6b1fb6%40googlegroups.com.

[go-nuts] Re: distributed runtime

[ffm2002]

Am Montag, 6. Januar 2020 09:54:49 UTC+1 schrieb Brian Candler:
>
> On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote:
>>
>> in Amoeba a thread can be suspended, thereafter be sent to some other 
>> machine where it is resumed.
>>
>
> Thread migration doesn't solve the OP's issue, because threads share 
> memory with other threads: passing a copy of something is not the same as 
> passing a pointer to something, unless you have a way for writes through a 
> pointer to act on the original memory.
>

Yes, you are right with that. I was dreaming a bit ... To extend the 
channel-based communication model in Go to a distributed setting you need 
"all or nothing" garanteed delivery of an item that is inserted into some 
distributed channel. Otherwise, in case of item to be placed in a 
distributed channel gets lost, the application may sit.

What is useful here is supervision as in the actor model (see 1, 2). If two 
parties comminucate through a network and get communication problems, a 
third party resets >both< communication parties that thereafter start anew. 
This is the approach that made applications written in Erlang 
fault-tolerant and highly stable.

However, if you want to apply supervision for distributed Go channels you 
have to change from channels to actors - at least behind the scenes of the 
distributed channels. AFAIK, no one has done something like that for 
anything writen in Go. Nats is very reliable, but does not provide 
guaranteed "all or nothing" delivery.


[1] https://erlang.org/doc/design_principles/sup_princ.html
[2] https://doc.akka.io/docs/akka/2.5/general/supervision.html

-- 
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/194f0772-0940-4515-850d-da0b410bb7f8%40googlegroups.com.

[go-nuts] Re: A question !

[anderson . queiroz]

>
> 2 - What is the fastest resource to learn Golang ( efficiently ) 
>

For me the best thing was Effective Go 
https://golang.org/doc/effective_go.html
Helps to understand "the go way"of coding and the main characteristics of 
the language

-- 
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/3cba8190-1ead-42dc-a920-1c871059ad97%40googlegroups.com.

[go-nuts] Re: distributed runtime

[Brian Candler]

On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote:
>
> in Amoeba a thread can be suspended, thereafter be sent to some other 
> machine where it is resumed.
>

Thread migration doesn't solve the OP's issue, because threads share memory 
with other threads: passing a copy of something is not the same as passing 
a pointer to something, unless you have a way for writes through a pointer 
to act on the original memory.

Ruby has(*) something like this in DRb.  If you pass an object over DRb, 
then at the far end a proxy object is constructed, so that method calls on 
that object are relayed back to the original host.

Systems with immutable values / pass-by-value only (e.g. Erlang) avoid this 
issue, since it doesn't matter whether you have a reference to a copy or 
the the original.

Regards,

Brian.

(*) or had: it's many years since I used Ruby in anger.

-- 
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/9d358b31-ddf4-4548-af1e-cb0e42d25573%40googlegroups.com.

[go-nuts] Re: distributed runtime

[Brian Candler]

On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote:
>
> in Amoeba a thread can be suspended, thereafter be sent to some other 
> machine where it is resumed.
>

Thread migration doesn't solve the OP's issue, because threads share memory 
with other threads: passing a copy of something is not the same as passing 
a pointer to something, unless you have a way for writes through a pointer 
to act on the original memory.

Ruby has(*) something like this in DRb.  If you pass an object over DRb, 
then at the far end a proxy object is constructed, so that method calls on 
that object are relayed back to the original host.

Systems with immutable values / pass-by-value only (e.g. Erlang) avoid this 
issue, since it doesn't matter whether you have a reference to a copy or 
the the original.

Regards,

Brian.

(*) or had: it's many years since I used Ruby in anger.

-- 
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/3f31d4d6-6598-4c04-a612-46e1a2ec728e%40googlegroups.com.

[go-nuts] Re: distributed runtime

[ffm2002]

Have you heard of the Amoeba distributed OS? See 
https://en.wikipedia.org/wiki/Amoeba_(operating_system). Well, in Amoeba a 
thread can be suspended, thereafter be sent to some other machine where it 
is resumed. That you can't do with goroutines of course (and goroutines 
pursue a different approach anway). But I think you could take some ideas 
from Amoeba. There is also Plan9 to look at, see 
https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs or Sprite 
(https://en.wikipedia.org/wiki/Sprite_(operating_system).

All those things are bloody awful interesting things. Unhappily, to get 
anything accomplished that comes only near any of those things would be 
hell of a lot of work ...

-- 
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/fd966422-3b2f-41ff-b6e2-9eb913ef5b21%40googlegroups.com.