Nice to Have: No more locking
bhuvy2 opened this issue · comments
Who uses mutexes? (Joke). Tornado design would really rather us be using callback yielding -- akin to the nodejs callback style -- instead of locking.
https://stackoverflow.com/questions/47279937/in-tornado-is-threadpoolexecutor-thread-safe
I'm pretty sure there is an easier way without making the code too ugly with yielding. Ideally we have an object that keeps track of these variables instead it being inside the service handler calls ourself.
What is the benefit of this? It feels like it would just make things less linear and more complicated, and I am curious if this actually brings performance gains or something that would make that worth it.
It just tends to be a clear programming intent. Locks are useful when the programming language doesn’t have a concept of coupling data and concurrency (like in C) but in most higher level languages, shared object handle their own concurrency. In the case of tornado, it would be registering a callback or awaiting on a function on the object
No real performance gains because we aren’t cpu bound. If the team thinks we won’t need much more locking, we don’t need to move to this
I could look into this. Could you point me to the thread-safe callback (ish) mechanism that tornado might use?
We use a lock only in one place and it would actually be nice if I could make that a callback. It would help me resolve #24 in a cleaner way.