[go-nuts] Re: crypto/tls/generate_cert.go: Should it be used? And how can it be used?

[b.ca...@pobox.com]

On Sunday, 29 November 2020 at 21:09:24 UTC Jeroen N. Witmond wrote:

>  go run `locate generate_cert.go` --host 127.0.0.1 --rsa-bits=2048 --ca 
>
>
That will only work if there's exactly one instance of generate_cert.go on 
your filesystem.

A better command is:
go run "$(go env GOROOT)/src/crypto/tls/generate_cert.go" ...etc

Or you can just download generate_cert.go directly from github 

.

Or should crypto/tls/generate_cert.go not be referred to at all?
>
>
I think it's helpful to mention it.  It's not hard to find - after all, it 
does say it's in crypto/tls.

-- 
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/2984eada-27b1-4e59-82a5-e254e5caa91bn%40googlegroups.com.

Re: [go-nuts] Trying to understand HTTP connection pooling behaviour - new DNS lookup

[b.ca...@pobox.com]

> My actual query was to learn how the removal of the broken connection is 
done.

Ah OK.  I'm not familiar with this code (net/http/transport.go), and you've 
already shown that the PutIdleConn trace action isn't called.  Maybe this 
comment is helpful:

if pconn.isBroken() || tooOld {
// If either persistConn.readLoop has 
marked the connection
// broken, but Transport.removeIdleConn has 
not yet removed it
// from the idle list, or if this 
persistConn is too old (it was
// idle too long), then ignore it and look 
for another. In both
// cases it's already in the process of 
being closed.
list = list[:len(list)-1]
continue
}

Otherwise someone else can answer more specifically.

-- 
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/613e3778-7892-4ab9-8cc8-6db1a3e8f966n%40googlegroups.com.

Re: [go-nuts] Trying to understand HTTP connection pooling behaviour - new DNS lookup

[b.ca...@pobox.com]

Unless you timestamp those log lines, I don't see any evidence that the DNS 
query is done when the godoc server shuts down.  Could it not just be that 
after the 2 second sleep, when it's time to make a new connection, it finds 
that the pool is empty so has to do a lookup to establish a new connection?

I've tested this myself, using your code and apache running on the local 
server.

$ go run httpclient.go http://localhost:80/
DNS Start Info: {Host:localhost}
DNS Done Info: {Addrs:[{IP:127.0.0.1 Zone:}] Err: Coalesced:false}
Got Conn: {Conn:0xc10070 Reused:false WasIdle:false IdleTime:0s}
Put Idle Conn Error: 
Resp protocol: "HTTP/1.1"
Sleeping now

Got Conn: {Conn:0xc10070 Reused:true WasIdle:true IdleTime:2.000554686s}
Put Idle Conn Error: 
Resp protocol: "HTTP/1.1"
Sleeping now
*<< at this point I "systemctl stop apache2" in another terminal >>*
*<< nothing happens until the 2 seconds is up, and then I see: >>*

DNS Start Info: {Host:localhost}
DNS Done Info: {Addrs:[{IP:127.0.0.1 Zone:}] Err: Coalesced:false}
Got error in making request: Get "http://localhost:80/": dial tcp 
127.0.0.1:80: connect: connection refused
Sleeping now

DNS Start Info: {Host:localhost}
DNS Done Info: {Addrs:[{IP:127.0.0.1 Zone:}] Err: Coalesced:false}
Got error in making request: Get "http://localhost:80/": dial tcp 
127.0.0.1:80: connect: connection refused
Sleeping now
^Csignal: interrupt

So as far as I can tell, the client tries to re-use the existing connection 
from the pool, finds there isn't one (or it's broken), and therefore tries 
to establish a new connection - which of course requires a lookup of the 
hostname in the URL.

Aside: I'd say the trace hooks "DNSStart" and "DNSDone" are somewhat 
misnamed, because the hostname resolution isn't necessarily done via DNS - 
in both your example and mine it's done via /etc/hosts.  But the intention 
is clear.

-- 
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/bb366eb5-c7df-452a-9549-281543b1b6d4n%40googlegroups.com.

[go-nuts] Re: Trying to understand HTTP connection pooling behaviour - new DNS lookup

[b.ca...@pobox.com]

Do you see a forward or reverse DNS lookup being made?

Can you provide a standalone program which demonstrates this behaviour?

I am wondering if either (a) something is logging when the connection is 
terminated, or (b) a new connection is automatically being made and put 
into a pool.

On Saturday, 28 November 2020 at 01:27:32 UTC amits...@gmail.com wrote:

> Hi, it seems that the http client automatically performs a DNS lookup when 
> an existing connection is terminated by the server. I simulated it via 
> changing the IP address in /etc/hosts.
>
> Can someone point me to the code where this logic is checked?
>
> I am looking at https://golang.org/src/net/http/transport.go but haven’t 
> found something yet - quite a beginner here.
>
> Thanks,
> Amit.
>
>

-- 
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/86f347d0-862f-4922-b2e4-e8835858ae90n%40googlegroups.com.

[go-nuts] Re: Give the zero time value a location, and it won't survive a roundtrip to JSON?

[b.ca...@pobox.com]

I didn't think that AD was a thing, even though RFC 3339 says it is.

Wikipedia says that dates in Common Era 
 and Dionysius BC/AD 
 are equivalent,  and that 1BC 
led straight onto 1AD.

-- 
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/540a6f0f-df1a-4e0f-9b74-a216e8e0fb45n%40googlegroups.com.

Re: [go-nuts] How to detect HTTP client stop polling at the server side

[b.ca...@pobox.com]

I should add: using channels often means the mutex is not required.

Imagine, for example, that you want a concurrency-safe counter (that 
multiple goroutines can read, increment and decrement).  You can put the 
counter value into a buffered channel:

counter := make(chan int, 1)
counter <- 0

Then you pull the value out of channel while you're working on it, and put 
it back when you're finished.

// Read counter
cv := <- counter
fmt.Println("Counter is %d", cv)
counter <- cv

// Increment counter
counter <- (<-counter + 1)

This is all safe because only one goroutine has possession of the counter 
value at any time.  Just make sure you always put it back (it can be 
helpful to write functions to do the accessing, and use 'defer' to put the 
value back)

-- 
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/c6de9b79-857c-41fd-bcb2-f62f1ddd7e71n%40googlegroups.com.

Re: [go-nuts] concurrency safety

[b.ca...@pobox.com]

On Friday, 27 November 2020 at 10:32:11 UTC oyvin...@teigfam.net wrote:

> Thread safety, concurrency safety, goroutines safety. The same stuff to 
> me.  
>
> It's important that concurrent goroutines don't interfere with each other 
> in such a way that internal state is compromised by other goroutines. 
> Typically through access to internal data, through pointers.
>

Not just that, but also:

-  any global variables.  Even reading an 'int' while some other goroutine 
is updating it is unsafe; it may give undefined behavior.

- concurrent read and write accesses to the same map or slice can cause the 
program to panic.  Note that map and slice values contain hidden pointers 
inside them.  So if two goroutines have the same map or slice value, they 
are aliasing to the same underlying data.

These can trip up people used to (say) Python, where such accesses are 
atomic - primarily because of Python's Global Interpreter Lock.

(There is sync.Map  which is 
concurrency-safe, but if you need this, there's probably a better solution 
in your architecture)
 

> If only go channels are used to communicate between goroutines, than that 
> case is closed. That's one of the reasons they exist - also in other 
> similar languages, with that aspect often based on CSP.
>

Here's a video explaining how channels can replace various concurrency 
primitives: it's worth getting your head around.
https://www.youtube.com/watch?v=5zXAHh5tJqQ

-- 
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/57144fb7-712b-4bde-9ed4-f98c06c27241n%40googlegroups.com.

Re: [go-nuts] How to detect HTTP client stop polling at the server side

[b.ca...@pobox.com]

On Friday, 27 November 2020 at 06:14:48 UTC Afriyie Abraham Kwabena wrote:

> What I would like to ask is, using mutex OK and if not the best way of 
> solving it, how can i use
> channels in this case.
>

There's nothing wrong with mutex, but you can use channels for a more 
native-Go experience.
This video is well worth 
watching: https://www.youtube.com/watch?v=5zXAHh5tJqQ

In short, you can get mutex or semaphore-like behaviour by having a channel 
with fixed depth, and putting/pulling values from it.
Playground 

mutex := make(chan struct{}, 1)
...

mutex <- struct{}{}
... do stuff
<-mutex

-- 
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/a3c1e84d-5d68-4862-a94a-9180ae943485n%40googlegroups.com.

[go-nuts] Re: Carting int to bool and the reverse for bit hacking ?

[b.ca...@pobox.com]

That's fantastic.  Paste in

int Test0(int v, int v1, int v2, int v3)
{
 return v == v1 || v == v2 || v == v3;
}

and then the the compiler options to -O3.

-- 
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/563867d6-b62f-4234-b16b-6c89fbe6fc5cn%40googlegroups.com.

[go-nuts] Re: Carting int to bool and the reverse for bit hacking ?

[b.ca...@pobox.com]

On Friday, 20 November 2020 at 09:26:57 UTC christoph...@gmail.com wrote:

> The use case I have to test if an integer is in a quite small constant set 
> of integers. With bool <-> int conversion, we can use binary operation like 
> this for instance which would be valid in C
>
> r := int(bool(v^v1))(bool(v^v2))(bool(v^v3))
>
>
FWIW, here's some complete C:

#include 
#include 

int Test0(int v, int v1, int v2, int v3)
{
 return v == v1 || v == v2 || v == v3;
}

int Test1(int v, int v1, int v2, int v3)
{
int r = (int)((bool)(v^v1)) & (int)((bool)(v^v2)) & (int)((bool)(v^v3));
return !r;
}

int Test2(int v, int v1, int v2, int v3)
{
int r = !!(v^v1) & !!(v^v2) & !!(v^v3);
return !r;
}

int main(void)
{
printf("%d\n", Test0(5, 1, 2, 4));
printf("%d\n", Test0(5, 1, 2, 5));
printf("%d\n", Test1(5, 1, 2, 4));
printf("%d\n", Test1(5, 1, 2, 5));
printf("%d\n", Test2(5, 1, 2, 4));
printf("%d\n", Test2(5, 1, 2, 5));
return 0;
}


Test environment:

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Using gcc -s, I see that Test1 and Test2 do indeed compile without branches 
(using setne) whilst Test0 has branches. However with flag -O3, all three 
functions compile to identical highly-compact code without branches.

I think the moral is: don't waste your time trying to outsmart the compiler.

It's true that Go's compiler doesn't currently optimise this case, but new 
optimisations are being added over time.

-- 
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/5b4473f4-aab5-478d-91e7-3e0268671d2en%40googlegroups.com.

[go-nuts] Re: Carting int to bool and the reverse for bit hacking ?

[b.ca...@pobox.com]

On Friday, 20 November 2020 at 09:26:57 UTC christoph...@gmail.com wrote:

> A handy feature of bool <-> int conversion is that true is converted to 1 
> and any integer different of zero to true. As a consequence, when we write 
> int(bool(x)) we get 0 when x is 0, and 1 when x is not 0.
>

I don't think you've tried this with Go.
Playground 

./prog.go:9:15: cannot convert x (type int) to type bool

 It doesn't work the other way either: e.g. int(v ^ v1 != 0)

./go1.go:9:13: cannot convert v ^ v1 != 0 (type untyped bool) to type int



> This is to be compared with 
>
> r := v==v1 || v==v2 || v==v3
>
> The second form is of course more readable, but will also have a 
> conditional branch at each ||.
>


You should compare the generated machine code before saying one is better 
than the other.  If int(bool(x)) worked, it might also have a conditional 
branch; that is, it would presumably be the same as int(x != 0). In that 
case, your code becomes int(v^v1 != 0) which may or may not compile to the 
same code as int(v != v1).

To see the assembly language:  go build -gcflags -S myprog.go

Note that

> r := (v^v1)*(v^v2)*(v^v3)

risks integer overflow and may give the wrong answer. Playground 


Apart from this, I think you're trying to micro-optimise.  Do you have code 
which is measurably affected by the problem you describe, i.e. by actual 
profiling?  Modern processors have optimisations to deal with branches, 
e.g. speculative execution. Also, if you're dealing with data which is not 
in cache, then DRAM access is orders of magnitude slower than the CPU - 
i.e. the CPU cost is almost free compared to the DRAM access cost.

-- 
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/38d981a1-7579-4cdc-b166-0d6d1b43da8bn%40googlegroups.com.