Lock and Unlock in conhost should decouple Ctrl+C dispatch and use smarter handling #2141
Labels
Area-Server
Down in the muck of API call servicing, interprocess communication, eventing, etc.
Issue-Task
It's a feature request, but it doesn't really need a major design.
Product-Conhost
For issues in the Console codebase
Milestone
The Lock and Unlock procedures in Conhost.exe are fraught with error.
For one, we are using intricate details of how many recursive entries there are on the lock to count when it is fully unlocked and dispatch Ctrl+C events. We're not supposed to be dependent on the lock count at all.
Additionally, there's multiple layers at which the locks can be processed, some of which DO dispatch the Ctrl+C events on the last unlock and some of which do NOT.
Finally, the lock/unlock procedure is bad in that it is easy to not unlock something since it's not in any sort of smart RAII-type object. This is sort of mitigated by wil::scope_exit in many places, but that function is also discouraged when you can use something better.
This issue encompasses rooting around and finding a better overall way to do all of this.
It does NOT encompass more granular locks than already exist.
The text was updated successfully, but these errors were encountered: