Closed bruno- closed 3 years ago
Thanks for digging into this. I'll take a look tomorrow. Yes, pipes introduce some tricky race conditions... this particular code is non-trivial :p
I did not have a chance to look at this but it's on my radar for early next week.
Hi, sorry to push back on this, but do you mind rebasing on master and restarting this discussion, taking into consideration the transient task PR that was recently merged? Thanks and apologies for taking so long to come back to this.
The fix proposed in this PR is hacky. Better solution is in #63 so I'm closing this PR in favor of that one.
Hi,
after using
Async::HTTP::Body::Pipe
as pointed out in #55 I started getting these exceptions:The code to reproduce:
The above is a simple, but contrived example. I was getting the same error when making many requests with a code similar to example from #55.
Here's the explanation why I think that happens:
#reader
async task started in#initialized
method runs completely synchronously. The@input.read
from#reader
method will run without ever blocking.ensure
block in#reader
method will mistakenly close the@head
socket before the#writer
method ever started.https://github.com/socketry/async-http/blob/0e17f9086f73a3d55f907aaf6349e278de61fd44/lib/async/http/body/pipe.rb#L75
#writer
task starts, it will error on this line (because@head
is closed):https://github.com/socketry/async-http/blob/0e17f9086f73a3d55f907aaf6349e278de61fd44/lib/async/http/body/pipe.rb#L85
I tried writing a spec and implementing a fix - but I'm not happy with either of them.
master
, doesn't actually fail. The spec throws an error, but it gets "lost" in a "background fiber". Any suggestions? I'd be glad to improve this.@writer
in the#initialize
method. The last line of the#reader
method could then be@head.close if defined(@writer) && @writer.nil?
. Both approaches make the code less clear, so any pointers are welcome!Thanks