Re: [go-nuts] Races in net/http when redirecting request - expected?

[Uzondu Enudeme]

According to the doc on client.Do, a 307 or 308 redirect preserves the original
http method and body provided that the request.GetBody function is defined

My thought then is that access to reads and writes on the req.Body must
be serialized to avoid a race condition.

Using a mutex for this prevented the race conditions.

My own question then is, what is the implication of serializing such access.
Wouldn't that have been the implementation if the stdlib was to make the 
req.Body
safe during a redirect?

- Uzondu

> On 5 Mar 2019, at 3:23 PM, virra...@gmail.com wrote:
> 
> I've been playing with server which redirects requests but then I noticed 
> weird races.
> What is odd that if these races are expected it would mean that using `*File` 
> in `req.Body`, for requests which are redirected, is not safe - this is 
> because we have races between `Read` and `Close`.
> 
> I've run following script with: `go run -race concept.go`
> 
> package main
> 
> import (
>   "crypto/rand"
>   "fmt"
>   "io"
>   "io/ioutil"
>   "net/http"
>   "sync"
>   "time"
> )
> 
> const (
>   addr1 = "localhost:8060"
>   addr2 = "localhost:8061"
> )
> 
> type customReader struct {
>   iter int
>   size int
> }
> 
> func (r *customReader) Read(b []byte) (int, error) {
>   maxRead := r.size - r.iter
>   if maxRead == 0 {
>   return 0, io.EOF
>   }
>   if maxRead > len(b) {
>   maxRead = len(b)
>   }
>   n, err := rand.Read(b[:maxRead])
>   r.iter += maxRead
>   return n, err
> }
> 
> func (r *customReader) Close() error {
>   // Uncomment this for even more races :((
>   // r.iter = 0
>   return nil
> }
> 
> func (r *customReader) Reset() {
>   r.iter = 0
> }
> 
> func second(w http.ResponseWriter, r *http.Request) {
>   ioutil.ReadAll(r.Body)
> }
> 
> func first(w http.ResponseWriter, r *http.Request) {
>   http.Redirect(w, r, "http://"+addr2+"/second";, 
> http.StatusTemporaryRedirect)
> }
> 
> func main() {
>   mux1 := http.NewServeMux()
>   mux1.HandleFunc("/first", first)
>   srv1 := http.Server{
>   Addr:addr1,
>   Handler: mux1,
>   }
>   go func() {
>   err := srv1.ListenAndServe()
>   fmt.Printf("err: %v", err)
>   }()
> 
>   mux2 := http.NewServeMux()
>   mux2.HandleFunc("/second", second)
>   srv2 := http.Server{
>   Addr:addr2,
>   Handler: mux2,
>   }
>   go func() {
>   err := srv2.ListenAndServe()
>   fmt.Printf("err: %v", err)
>   }()
> 
>   time.Sleep(time.Second)
>   client := http.DefaultClient
> 
>   wg := &sync.WaitGroup{}
>   for i := 0; i < 1000; i++ {
>   reader := &customReader{size: 90}
>   wg.Add(1)
>   go func(r *customReader) {
>   for {
>   req, err := http.NewRequest(http.MethodPut, 
> "http://"+addr1+"/first";, r)
>   if err != nil {
>   fmt.Printf("%v", err)
>   }
>   req.GetBody = func() (io.ReadCloser, error) {
>   return &customReader{size: 90}, nil
>   }
> 
>   if resp, err := client.Do(req); err != nil {
>   // fmt.Printf("error: %v", err)
>   } else if resp.StatusCode >= 
> http.StatusBadRequest {
>   // fmt.Printf("status code: %d", 
> resp.StatusCode)
>   }
> 
>   // Reset reader and try to reuse it in next 
> request
>   r.Reset()
>   }
> 
>   wg.Done()
>   }(reader)
>   }
> 
>   wg.Wait() // infinite wait
> 
>   srv1.Close()
>   srv2.Close()
> }
> 
> 
> 
> Races which are occuring:
> 
> ==
> WARNING: DATA RACE
> Write at 0x00c0003e00a0 by goroutine 87:
>   main.main.func3()
>   /home/januszm/concept.go:43 +0x55
> 
> Previous write at 0x00c0003e00a0 by goroutine 3899:
>   [failed to restore the stack]
> 
> Goroutine 87 (running) created at:
>   main.main()
>   /home/januszm/concept.go:91 +0x3b0
> 
> Goroutine 3899 (finished) created at:
>   net/http.(*Transport).dialConn()
>   /usr/local/go/src/net/http/transport.go:1358 +0xb89
>   net/http.(*Transport).getConn.func4()
>   /usr/local/go/src/net/http/transport.go:1015 +0xd0
> ==
> ==
> WARNING: DATA RACE
> Write at 0x00c0002ca750 by goroutine 488:
>   main.main.func3()
>   /home/januszm/concept.go:43 +0x55
> 
> Previous write at 0x00c0002ca750 by goroutine 1951:
>   main.(*customReader).Read()
>   /home/januszm/concept.go:33 +0x156
>   net/h

Re: [go-nuts] does struct pointer *a == *b make sense?

[Uzondu Enudeme]

Yes. They are equal.

According to the go language spec:


   - Struct values are comparable if all their fields are comparable. Two
   struct values are equal if their corresponding non-blank
    fields are equal.

You can go through that part of the spec for greater understanding of the
equality operator.

https://golang.org/ref/spec#Comparison_operators


Ragards,

Uzondu


On Fri, Nov 23, 2018, 04:06 Youqi yu  type T {
>  Name string
> }
> a := &T{Name:"test"}
> b :=&T{Name:"test"}
> *a == *b
> Hi, all, I am beginner at golang, I have a question that when compare
> struct equality, I was told to use reflect.DeepEqual or make my own
> function. but the result of above code is true. Does it mean struct a
> equals struct b?
> thx.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] A treemap implemented in go

[Uzondu Enudeme]

I've taken note of all your comments.
I've added some to my todo list as per the package and made a few
improvements.

Note that none of these are "the right way", they give you options to make
> the code more reusable.


I completely get this.

Thanks for your time.

Uzondu

On Wed, Oct 3, 2018 at 2:08 PM Tristan Colgate  wrote:

> In case you haven't already checked it out, you can now see your package
> at:
>
> https://godoc.org/github.com/willpoint/treemap
>
> You can do a sort of "GoDoc Driven Design" here, look at the godoc, and
> decide if the interface is something you would like to use.
>
> Some suggestions:
>
> - A destination io.Writer is tradionally places as the first argument to a
> function.
> - DrawTreemap doesn't actually mention that the package writes SVG, the
> function names could make it clearer.
> - Along a similar line, maybe you could have a DrawToSVG that took an
> *svg.SVG instead of a writer (or, better still, define an WriteSVG
> interface that just includes the methods on the SVG that you use, this
> would allow others to swap out the SVG implementation that was used. This
> could allow an SVG to be drawn into an existing svg the user is building up
> in sections.. DrawTreemap could still fall back to the default one).
> - similarly, you could provide a method that draws to a pre-existing image
> - in some scenarios, width/height might be inferrable, from some container
> you might want to draw something in to.
> - building on a richer underlying drawing abstraction might make things
> more re-usable, The SVG interface thing above helps with that, you could
> also look at something like https://godoc.org/github.com/llgcode/draw2d 
> (though
> that obviously introduces depedencies).
>
> Note that none of these are "the right way", they give you options to make
> the code more reusable.
>
>
> On Wed, 3 Oct 2018 at 13:49 Uzondu Enudeme  wrote:
>
>> Hi Tristan,
>>
>> Thanks again for your helpful feedback. Based on your observations,
>> here's what I've done so far:
>>
>> This would be more useful as a package than a single program. You could
>>> move main into an example/ folder and keep the rest of the content in the
>>> top level as a package. Move the explanatory comment up as a Package
>>> comment.
>>
>>
>> I have now moved main to an example folder and left the rest as a
>> package. I then defined an interface `TreeMapper` that represents any type
>> that can be drawn by the treemap's DrawTreemap function.
>>
>> The standard library includes color handling, check the image package.
>>
>> I haven't yet figured this out. I'd look more carefully into the image
>> package.
>>
>> The strconv wrapper is probably a bit excessive for the sake of the cast
>>> (you might not need it if you use color.Color anyway)
>>
>> I removed the strconv wrapper, it really seemed excessive. I'm still yet
>> to implement the use of color.
>>
>> The orientation might be better off as a tyoed parameter, look for docs
>>> on typed constants.
>>
>>
>> I read this article <https://blog.golang.org/constants> on the subject
>> and found it really great! I have updated to code to reflect that.
>>
>> Any further advice would be greatly appreciated. The link still remains
>> https://github.com/willpoint/treemap
>>
>> Thanks,
>>
>> Uzondu
>>
>> On Wed, Oct 3, 2018, 09:13 Uzondu Enudeme  wrote:
>>
>>> Thanks a lot Tristan,
>>>
>>> The points you mentioned are really all very important ones.
>>>
>>> I'm currently following all your suggestions and would repost the link
>>> to the updated code in case I missed some points.
>>>
>>>
>>> On Wed, Oct 3, 2018, 06:52 Tristan Colgate  wrote:
>>>
>>>> A couple of quick observations.
>>>>
>>>> This would be more useful as a package than a single program. You could
>>>> move main into an example/ folder and keep the rest of the content in the
>>>> top level as a package. Move the explanatory comment up as a Package
>>>> comment.
>>>>
>>>> The standard library includes color handling, check the image package.
>>>>
>>>> The strconv wrapper is probably a bit excessive for the sake of the
>>>> cast (you might not need it if you use color.Color anyway)
>>>>
>>>> The orientation might be better off as a tyoed parameter, look for docs
>>>> on type

Re: [go-nuts] A treemap implemented in go

[Uzondu Enudeme]

Hi Tristan,

Thanks again for your helpful feedback. Based on your observations, here's
what I've done so far:

This would be more useful as a package than a single program. You could
> move main into an example/ folder and keep the rest of the content in the
> top level as a package. Move the explanatory comment up as a Package
> comment.


I have now moved main to an example folder and left the rest as a package.
I then defined an interface `TreeMapper` that represents any type that can
be drawn by the treemap's DrawTreemap function.

The standard library includes color handling, check the image package.

I haven't yet figured this out. I'd look more carefully into the image
package.

The strconv wrapper is probably a bit excessive for the sake of the cast
> (you might not need it if you use color.Color anyway)

I removed the strconv wrapper, it really seemed excessive. I'm still yet to
implement the use of color.

The orientation might be better off as a tyoed parameter, look for docs on
> typed constants.


I read this article <https://blog.golang.org/constants> on the subject and
found it really great! I have updated to code to reflect that.

Any further advice would be greatly appreciated. The link still remains
https://github.com/willpoint/treemap

Thanks,

Uzondu
On Wed, Oct 3, 2018, 09:13 Uzondu Enudeme  wrote:

> Thanks a lot Tristan,
>
> The points you mentioned are really all very important ones.
>
> I'm currently following all your suggestions and would repost the link to
> the updated code in case I missed some points.
>
>
> On Wed, Oct 3, 2018, 06:52 Tristan Colgate  wrote:
>
>> A couple of quick observations.
>>
>> This would be more useful as a package than a single program. You could
>> move main into an example/ folder and keep the rest of the content in the
>> top level as a package. Move the explanatory comment up as a Package
>> comment.
>>
>> The standard library includes color handling, check the image package.
>>
>> The strconv wrapper is probably a bit excessive for the sake of the cast
>> (you might not need it if you use color.Color anyway)
>>
>> The orientation might be better off as a tyoed parameter, look for docs
>> on typed constants.
>>
>>
>>
>>
>>
>> On Tue, 2 Oct 2018, 23:06 Uzondu Enudeme,  wrote:
>>
>>> Hi everyone,
>>>
>>> I've been following the golang-nuts' email threads for a while now and
>>> I'm amazed at how much I've learnt seeing ways solutions are profferred.
>>>
>>> I implemented a treemap for data visualization, and wrote a process.md
>>> file giving some sort of background and detail.
>>>
>>> I want to use this opportunity to learn what I could have done better by
>>> asking that the code be reviewed, it's in a single main.go file at
>>> github.com/willpoint/treemap
>>>
>>> Thanks in advance for the time that would be spent and any advice given.
>>>
>>>
>>> Uzondu
>>>
>>>
>>> --
>>> 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.
>>>
>>

-- 
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] A treemap implemented in go

[Uzondu Enudeme]

Thanks a lot Tristan,

The points you mentioned are really all very important ones.

I'm currently following all your suggestions and would repost the link to
the updated code in case I missed some points.


On Wed, Oct 3, 2018, 06:52 Tristan Colgate  wrote:

> A couple of quick observations.
>
> This would be more useful as a package than a single program. You could
> move main into an example/ folder and keep the rest of the content in the
> top level as a package. Move the explanatory comment up as a Package
> comment.
>
> The standard library includes color handling, check the image package.
>
> The strconv wrapper is probably a bit excessive for the sake of the cast
> (you might not need it if you use color.Color anyway)
>
> The orientation might be better off as a tyoed parameter, look for docs on
> typed constants.
>
>
>
>
>
> On Tue, 2 Oct 2018, 23:06 Uzondu Enudeme,  wrote:
>
>> Hi everyone,
>>
>> I've been following the golang-nuts' email threads for a while now and
>> I'm amazed at how much I've learnt seeing ways solutions are profferred.
>>
>> I implemented a treemap for data visualization, and wrote a process.md
>> file giving some sort of background and detail.
>>
>> I want to use this opportunity to learn what I could have done better by
>> asking that the code be reviewed, it's in a single main.go file at
>> github.com/willpoint/treemap
>>
>> Thanks in advance for the time that would be spent and any advice given.
>>
>>
>> Uzondu
>>
>>
>> --
>> 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.
>>
>

-- 
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] A treemap implemented in go

[Uzondu Enudeme]

Hi everyone,

I've been following the golang-nuts' email threads for a while now and I'm
amazed at how much I've learnt seeing ways solutions are profferred.

I implemented a treemap for data visualization, and wrote a process.md file
giving some sort of background and detail.

I want to use this opportunity to learn what I could have done better by
asking that the code be reviewed, it's in a single main.go file at
github.com/willpoint/treemap

Thanks in advance for the time that would be spent and any advice given.


Uzondu

-- 
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: Language is a platform, which golang still does not pay attention to !!!

[Uzondu Enudeme]

>
>
>  > they are both not just programming languages but also platforms. They 
> are almost the same in Windows and Linux. That's why java and php are very 
> popular in recent days.


 Having worked with Go for just a little over a year, I would like to add 
that the Go community in itself has also become a platform. That to me is 
priceless. The language has become a platform not just by the new and 
improved programming culture but more importantly what that culture 
enables. The unity of purpose in the community overpowers whatever lack 
there may seem to be in the uniformity of use across platforms.
I believe that should be what a platform does. Enabling people to work 
together to concurrently meet their respective needs (pun intended).

Uzondu. 


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