https://bugs.winehq.org/show_bug.cgi?id=50292
--- Comment #11 from Jacek Caban jacek@codeweavers.com --- (In reply to Zebediah Figura from comment #10)
The only problem with that is that if we run out of space in the fd cache, the only effect is we have to go to the server each time. If we run out of space in the TID/addr or TID/TEB mappings, the functions can't work. Maybe that's not worth worrying about, though...
We can ensure that the cache slot is allocated somewhere in NtCreateThreadEx, where we can properly propagate error.
You mean, map to the value directly rather than mapping to the TEB and looking up the value from there?
Yes.
For PE side of things, I wonder if you really need so complicated wait entry allocation. Could we just store wait entry on waiting thread's stack?
We need some way to append and arbitrarily remove it from a list of waiting threads. It would have been better than the original approach (i.e. iterating over TEBs), but it would still require locking (afaik only singly linked lists can be lock-free, and you can't pop from the middle of one).
Reading it again in more details, it's probably better to stick with your current solution for PE part.
FWIW, we wouldn't need to pop from a middle if we had a separated lists for each address. The problem would be lock-free mapping from input address to such a single listed list. This could be done, but 64-bit key size makes it much less appealing (than, say, 30-bit key for fd cache).