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