Issue with Patron deadlock when starting the server in a separate thread in the same process #26

myronmarston opened this Issue Nov 23, 2010 · 3 comments


None yet

5 participants


The tests for my VCR gem tests a bunch of different supported HTTP libraries including Patron. The specs and cukes start up a local rack server and than make requests to it. The rack server is started in a separate thread when needed so that it automatically shuts down when the specs/cukes end.

This doesn't work so well for Patron...the process freezes. I've attempted to work around it by forking a process instead of using a thread, but that introduces some additional complexity and has some other problems. It'd be preferable to fix the issue in Patron; the threading works fine for Curb, Typhoeus, Net::HTTP, HTTPClient and em-http-request.

I haven't spent much time troubleshooting it, but it appears that Patron uses blocking primitives that when the request is initiated, which causes deadlock since another thread is trying to start up the server.

mcmire commented Apr 18, 2011

I think I have run across this bug or a related bug as well... in starting up a Rack server within a separate thread and trying to hit it with Patron, it's not that I got a deadlock, Patron would just time out every time. However, hitting the same Rack app with Net::HTTP worked just fine. Also, if the Rack app was started in a fork block, hitting it worked too. I can provide more details if necessary.

@toland toland was assigned Jun 22, 2011
TwP commented Nov 15, 2011

Would you be willing to test this again with the head of the patron master branch? I believe some recent changes should address many of the threading issues.

julik commented May 14, 2016

I think the timeout issue has been fixed (it was a problem with request body being set via function pointers, so a body larger than N bytes would hang the fptr and consequently hang curl). I see that VCR still includes Patron compatibility and I presume it does pass tests ATM. @myronmarston if this is still relevant please reopen and I will try to look into it once more.

@julik julik closed this May 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment