thread.local support about bjoern HOT 5 CLOSED

Hey George, I'm not sure how much work this is to implement. I'm not against the idea of "bjoernlocals" in general as long as they don't require extensive changes, but to be honest I'm not interested enough in this feature to code it myself.

So if you really need thread locals you're probably better off using a different Web server (or implement the feature yourself, of course :-).

from bjoern.

Thanks for the reply, I'm afraid this is a deal breaker for me and I'd guess for many non trivial web apps. Most frameworks expose some sort of "global" objects such as the current request, db session, etc; without it you'd need to pass them explicitly in all function and method calls, starting from the top level wsgi app all the way down the stack. For multithreaded servers, thread locals is a natural fit for this. Async servers still face the same problem though, and they should either monkeypatch thread locals or offer an alternative mechanism for such request-specific "globals".

from bjoern.

As I said I'm not aversed to having some sort of thread locals in bjoern, it's just missing someone to implement it.

Maybe if more users demand this feature I'm going to try to implement it but you're the first one so far to request thread locals.

(Which either means nobody uses bjoern or it works well enough without thread locals [Django].)

from bjoern.

I discovered Contextual, a package that addresses the need for global state in a safe, context-dependent way. Probably worth a look for you or anyone else that comes across this problem.

Feel free to close this issue if it's not a priority.

from bjoern.

It doesn't seem to work. Here's a test script that sends two requests so that bjoern interrupts the handler after the yield. The counter doesn't start at 0 for the second "coroutine". https://gist.github.com/2057811

from bjoern.