This is typically not an issue with Django, as a regular view is single-threaded by nature. Yes, there are cases where there is value to perform some degree of parallelization of processing within a view - but in my experience, it’s rare, and when I need to do it, I don’t handle it via threading. Across 12 years now of working consistently with Django, I have never encountered a problem caused by threading issues. (Race conditions are a different situation, as they can also occur within an async environment if you’re not aware of all the cases where you can yield the CPU back to the reactor.)
This is where I think many people greatly over-estimate their needs. As I wrote in one of my posts above:
Now, if your application currently deals with this level of traffic, great! I’m happy for you and can respect the fact that you actually have this need. But you’d be in an extreme minority. On the other hand, if you’re with one of those companies with a “big idea” and that you need to “plan for the future”, I maintain you’re wasting effort. (I can name very few people in the first category. I could name hundreds of people in the latter, that ended up never needing it.)
Personally, if I had a “magic wand”, there wouldn’t be any attempt at integrating async within Django. Don’t get me wrong - I have always acknowledged that there is a need for an asynchronous framework - I just don’t think Django-as-is is the right “target”.
I think that if you’re looking to get the full benefits of async, it should be in a framework that is “async-to-the-core” (e.g. Twisted)
I’m sorry, I’m not sure I know which specific feature you’re asking about here.