[go-nuts] Re: Would this race condition be considered a bug?

[anmol via golang-nuts]

I'm considering only the case when there is a concurrent print of the 
context and also a concurrent context cancel.

On Friday, March 16, 2018 at 5:16:27 AM UTC-4, Jérôme Champion wrote:
>
> Any race is a bug. When there is a race, the compiler is free to do 
> whatever it wants.
>
> What do you want to do? Do you want to println before or after 
> cancelContext? In your example, println could even be executed during 
> cancelContext!
> Your example is not enough, such program : 
> https://play.golang.org/p/KJsYwu-ivjb would fix your problem, but I don't 
> think that's what you asked for :)
>
> Le vendredi 16 mars 2018 03:11:49 UTC+1, Anmol Sethi a écrit :
>>
>> https://play.golang.org/p/82Um1jSntBo
>>
>> Please run with the race detector to see the race.
>>
>> This race condition arises because private variables are read via 
>> reflection by the fmt package. Is there any elegant way to avoid such a 
>> race?
>>
>> -- 
>> Best,
>> Anmol
>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] gluo v0.0.2 released - Write your Go net/http server once, deploy it everywhere

[anmol via golang-nuts]

What do you think about offering a second variant to allow passing in the 
http server? It's possible one may want to set limits or other 
configuration on the HTTP server instead of using the default http server.

On Thursday, January 25, 2018 at 6:42:03 PM UTC-5, Dario Castañé wrote:
>
> I'm pleased to announce the launch of Gluo: a handy wrapper for net/http 
> applications that allows to deploy the exact same binary to AWS Lambda and 
> (bare-metal/virtual) servers.
>
> https://github.com/imdario/gluo
>
> If you want to use your current net/http code with little modification, 
> Gluo is your choice. It's a drop-in replacement: just call 
> gluo.ListenAndServe instead of http.ListenAndServe.
>
> PS: version 0.0.1 was released the same day as AWS announced their 
> official support for Go in AWS Lambda, but I waited for a second release in 
> order to improve code coverage.
>
> Dario Castañé
> dario.im
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] reverse proxy with ssl in less than 100 lines of code

[anmol via golang-nuts]

Here is a better way to redirect from HTTPS to 
HTTP: 
https://github.com/nhooyr/redirecthttp/blob/d87881e4fbfddb1614c9d0934ea97c4163903301/main.go#L10-L19

Also, you don't need a secure variable in the handler, just check for r.TLS.

On Thursday, December 28, 2017 at 12:10:16 PM UTC-5, jzs wrote:
>
> For those interested in hosting multiple golang apps on the same host 
> without using nginx/apache/[insert reverse proxy here].
>
> Shameless plug. I'm the author. But without 
> golang.org/x/crypto/acme/autocert it wouldn't have been possible.
>
>
> https://journal.sketchground.dk/entry/2017-11-25-minimal-reverse-proxy-in-go
>
> Any feedback is more than welcome,
>
> Thanks,
> Jens.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Is net.Conn concurrency-safe?

[anmol via golang-nuts]

Ah I see. You mean its obvious that multiple goroutines may invoke methods 
on a Conn simultaneously, your question is whether its safe or not, which 
the docs do not answer.

The docs definitely intend on meaning that it is in fact safe to invoke 
methods on a Conn simultaneously.

But I agree, the docs could be clarified. I think it would be best to open 
an issue on GitHub regarding this.

On Monday, December 18, 2017 at 9:48:09 AM UTC-5, Anmol Sethi wrote:
>
> Not sure where what is prompting your question, how are the docs 
> misleading? The docs are very clear, net.Conn is concurrency safe.
>
> On Monday, December 18, 2017 at 7:51:26 AM UTC-5, SP wrote:
>>
>> In the documentation for https://golang.org/pkg/net/#Conn, it's stated 
>> that 
>>
>> Multiple goroutines may invoke methods on a Conn simultaneously.
>>
>> My guess is this is not meant to imply that it is necessarily safe to do 
>> so. For instance, calls to Set*Deadline may create race conditions between 
>> goroutines. However, if this is true it also makes the quoted claim 
>> pointlessly self-evident.
>>
>> Am I missing something or is the documentation somewhat misleading here? 
>> You could argue (and it would be perfectly fair) that programmers should be 
>> aware of these sorts of obvious concurrency problems, but the misleading 
>> nature of the documentation has me questioning whether I can trust it at 
>> all.
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Is net.Conn concurrency-safe?

[anmol via golang-nuts]

Not sure where what is prompting your question, how are the docs 
misleading? The docs are very clear, net.Conn is concurrency safe.

On Monday, December 18, 2017 at 7:51:26 AM UTC-5, SP wrote:
>
> In the documentation for https://golang.org/pkg/net/#Conn, it's stated 
> that 
>
> Multiple goroutines may invoke methods on a Conn simultaneously.
>
> My guess is this is not meant to imply that it is necessarily safe to do 
> so. For instance, calls to Set*Deadline may create race conditions between 
> goroutines. However, if this is true it also makes the quoted claim 
> pointlessly self-evident.
>
> Am I missing something or is the documentation somewhat misleading here? 
> You could argue (and it would be perfectly fair) that programmers should be 
> aware of these sorts of obvious concurrency problems, but the misleading 
> nature of the documentation has me questioning whether I can trust it at 
> all.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why are can't struct field types not be used as types

[anmol via golang-nuts]

OP said he does not want to litter his code with helper types.

On Sunday, December 10, 2017 at 1:30:33 PM UTC-5, Kevin Malachowski wrote:
>
> Why not name the inner type? https://play.golang.org/p/8hyMLUVbCp

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Reading os.Stdin, Unbuffered

[anmol via golang-nuts]

Use https://godoc.org/golang.org/x/crypto/ssh/terminal#MakeRaw to set raw 
mode on the stdin terminal.

Then you can just read from os.Stdin into a single byte buffer. If the read 
completes, then a key was pressed.

On Tuesday, November 28, 2017 at 12:12:44 AM UTC-5, dc0d wrote:
>
> For example I want the program to exit, if any key has been pressed on 
> keyboard. I can not find any way to skip the wait for a necessary split 
> character (like '\n').
>
> On Monday, November 27, 2017 at 6:36:35 PM UTC+3:30, Jan Mercl wrote:
>>
>> On Mon, Nov 27, 2017 at 4:00 PM dc0d  wrote:
>>
>> > Is there a way to read from `os.Stdin` in an unbuffered way? (Not 
>> waiting for a `\n` or anything).
>>
>> n, err := os.Stdin.Read(buf)
>>
>> does not wait for `\n`. Or do you actually mean setting a terminal in raw 
>> mode? Because os.Stdin does not have to be a terminal.
>>
>>
>>
>> -- 
>>
>> -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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] does the syscall package allow zero bytes in the filename?

[anmol via golang-nuts]

Was the suggestion from this 
commit 
https://github.com/golang/go/commit/706832a0882c7300889238d5f4d476dc2ee83ad0 
ever implemented?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: dialing a name with multiple addresses

[anmol via golang-nuts]

I understand now. If the first IP fails, it uses the next one and so on 
until it runs out of IPs or the timeout occurs.

On Tuesday, September 27, 2016 at 5:23:18 PM UTC-4, Anmol Sethi wrote:
>
> For https://godoc.org/net#Dialer , it says "When dialing a name with 
> multiple IP addresses, the timeout may be divided between them." 
>
> Why? Wouldn't the name still be resolved to a single IP?
>
> E.g. if I have 5 IPs for example.com, one would be selected and used. Why 
> would the timeout need to be divided among them?
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.