Is this library/module thread-safe?

[SecurityForUs]

I'm looking to use this for a project I'm working on using Tornado and asynchronous calls, and for it to be viable I need this to be thread-safe. So, yeah, heh...basically, is it safe to use in threaded scenarios?

[sudorandom]

Some parts are and some parts aren't thread safe. However, I believe the biggest issue with using this library with an async library like tornado is that it will be blocking. Evented frameworks usually use a single thread and only do one thing once. When it gets to a call that is disk or network bound, it will let other things run until there is something to do with the socket/file handle. This is optimal because coroutines are less expensive than threads and CPU is way faster than network or disk IO.

If you are really using threads to work with blocking clients in tornado it should be fine as long as there isn't a chance that two threads can access one client at the same time. To be safe I would create one client for each thread that you're using.

[SecurityForUs]

Well I'm not using threads directly but using asynch and gen.Task(). So I guess its because I'm still waking up but am I going to run into issues with this?

[sudorandom]

I'm still waking up too so I think I left out saying the implications. So when I say 'blocking client' I mean that in frameworks like twisted and tornado if you don't deal with the fact that the call you're making is 'blocking' then literally nothing else in your IOLoop will be able to run until the blocking call is finished. Eventlet and gevent get around this by providing a way to monkeypatch TCP and/or HTTP calls in the python standard library so most 'blocking clients' will not have this negative effect. Unfortunately I have no idea if this is available in tornado...

If tornado doesn't have a way to monkeypatch TCP or HTTP, I recommend either making this call in another thread (I'm also not sure tornado has this build in but it's built into into twisted) or writing the functionality you need using the tornado http client using the swift reference as a guide.

So, my conclusion is that I would not use this library with tornado unless you know how to prevent it from blocking.

[SecurityForUs]

I appreciate the information, and I'll look into seeing what I can do in the meantime with it. :) I know this isn't the Tornado GitHub, but I was under the impression that if you use the asynchronous and gen.engine decorators it would take care of the issue of blocking, as long as you did something like this:

@tornado.web.asynchronous
@tornado.gen.engine
def put(self):
    resp = yield tornado.gen.Task(function_callback, args)

I could be wrong, I just started venturing into Tornado, but it's something I've been told and such so thought you might be able to address it.

[sudorandom]

I have to claim ignorance on that since I'm not that familiar with tornado.

[SecurityForUs]

Ah that's fine, same here really. All well, I think I have this figured out anyways, since I can use get_requests_client() instead of get_client(), and Requests is thread-safe, it should solve any potential issues.