Magically take care of threading issues, please.

[SurferJeffAtGoogle]

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.

[tmatsuo]

+1 I really like this idea

[dhermes]

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?

[SurferJeffAtGoogle]

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.

[SurferJeffAtGoogle]

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

[dhermes]

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.

[tseaver]

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.

[dhermes]

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.

[theacodes]

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?

[dhermes]

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

[theacodes]

tentatively raises hand

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

[dhermes]

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.

[SurferJeffAtGoogle]

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

[dhermes]

@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?

[theacodes]

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

I would be in favor of this.

[dhermes]

https://github.com/wbolster/happybase/blob/9cbd718c10a3089f234f1eac1236b631e1f8e7cd/happybase/pool.py

is my inspiration for such a thing.

[theacodes]

I was going to recommend peeking at urllib3, but that's actually quite nice and short.

[dhermes]

Well the long-term goal is to divorce ourselves from the transport layer in a clean way, but that also relies on googleapis/oauth2client#128 as well

[theacodes]

Ah, sorry, I was unclear, I just meant to take urllib3's connection pooling as an example.

I like happybase's approach. Is it possible for us to more or less hide this from the user?

[dhermes]

Yes I think we can hide it in the Client constructors.

[SurferJeffAtGoogle]

I like "hiding it in the Client constructor." If we use thread locals, I don't understand the advantage of also using a pool. Is that for when a thread terminates its thread local falls back into the pool? I have no idea what the lifetime of a thread on app engine looks like.

[dhermes]

The idea would be that the pool creates a thread local connection for the client to use:

• https://github.com/wbolster/happybase/blob/9cbd718c10a3089f234f1eac1236b631e1f8e7cd/happybase/pool.py#L128-L130
• https://github.com/wbolster/happybase/blob/9cbd718c10a3089f234f1eac1236b631e1f8e7cd/happybase/pool.py#L114

[SurferJeffAtGoogle]

Ok. That looks good.

[theacodes]

Just a bump on this.

Today I just noticed that one of my projects assumed client was threadsafe, and proceeded to explode.

[theacodes]

Could we not do something as trivial as have Connection.http return a context-local?

[dhermes]

I'm teaching a course this week. I'm happy to review PRs in the evening?

[theacodes]

I'll be traveling, but I can see what I can do next week (which is my last
week before holidays).

On Mon, Dec 7, 2015, 6:30 PM Danny Hermes [email protected] wrote:

I'm teaching a course this week. I'm happy to review PRs in the evening?

—
Reply to this email directly or view it on GitHub
#926 (comment)
.

[theacodes]

Superseded by the discussion over at #1346