Magically take care of threading issues, please.

I don't want to worry about connections and threads. I want to be able to pass API classes from thread to thread and have the classes take care of threading issues.

+1 I really like this idea

I like the idea too, but it is pretty abstract. Can you give an example where you have to deal with threading that you'd like the library to handle?

Yes, when I'm calling the code on app engine, my http handlers will be called from multiple threads. I can't share a connection/http object between them all because the underlying http object is not thread safe. I don't want to create a new http object for each request because then I lose the benefit of connection: keep-alive.

Also, I don't want to create a new http object for each request because then it has to re-authenticate.

In the short term I'd like to point to #908 and the custom code there using requests.

We'd like to address this, but if your needs are pressing, you may be happy with a short-term hack in the style described in that issue.

Given that we are moving to re-bind domain objects to clients (where clients encapsulate a connection), satisfying this goal is going to be tricky, unless the "foreign" thread is willing to pass in its client to methods which need a client.

@tseaver

A bigger issue may also be that httplib2 is not thread-safe. @tseaver You should check out how easily @mwitkow-io was able to make requests work in our library in a threaded environment in #908.

Pinging this issue as threadsafety for gcloud clients recently came up in discussion.

What's the status on this? Are client objects not threadsafe? If not, what needs to be done to allow that?

Also, if not, can we explicitly document that?

I think the best way to know is to write threaded code and see what happens. Anyone want to volunteer?

tentatively raises hand

I'll give a shot when I get a bit of free time.

I do know a little bit about this. For one, httplib2 is not thread safe. I have been advocating for a "divorce" from httplib2 or at least a way to give people other options (see googleapis/oauth2client#128). I feel like large structural changes should wait until googleapis/oauth2client#212 is complete though.

We already enable this with our library (#908) but it doesn't solve the auth problem for people until oauth2client catches up.

I coped with this issue by using thread-local instances of httplib2.Http.
https://github.com/GoogleCloudPlatform/pubsub-shout-csharp/blob/master/appengine-python-flask/pubsub.py

@SurferJeffAtGoogle

@SurferJeffAtGoogle It may be "faster" to avoid calling credentials = oauth2client.GoogleCredentials.get_application_default() in every single thread, but I think it's not so bad an approach.

We could manually add a connection or client pool that just binds to a thread local for the user?