Synchronized access to Response.transfer and Response.bytesResumed

[cmaglie]

I've been experiencing "race condition detected" errors during tests, I'm displaying a progress bar during download (using another goroutine), that's why those fields needs to be protected for concurrent access.

[cmaglie]

Mmmmmhhh... talked too early, after some more testing, there are still some problems (the goroutine that does the "progress bar" is blocked until the download completes, but this happens only for very long downloads).

[cmaglie]

Ok I've added another commit to the PR, this solved the issue for good this time.

[cavaliercoder]

Thanks for taking the time to submit this. It's a pretty complicated issue, and you've done well to solve it. I'm not sure if your approach is the way I wan't to move forward though - and it's entirely my fault.

When I introduced the transfer type I thought I had this really neat, reusable, thread-safe type that could be independently open sourced. I neglected to note that the reference to this new type was not thread-safe. I'd rather solve this issue by undoing my poor design choice and creating much more clearly defined ownership of memory.

The previous model implied two access rules:

• All writes to a Response before a transfer starts happen in a single goroutine, while the caller is blocked
• All writes after the transfer start happen in a single goroutine (the one doing the transfer) and are protected by mutex/atomic
• All reader after the transfer starts are thread-safe and protected by mutex/atomic/etc.

The problem is that Response.transfer is being read in another goroutine (not its thread-safe children), before the transfer starts.

I hope this might be solved with one or two lines of code.

[cavaliercoder]

Declined in favor of #29. Apologies and gratitude!

[cmaglie]

No problem, and thanks for doing a proper fix!