[Bug 50292] Process-local synchronization objects use private interfaces into the Unix library

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50292

--- Comment #11 from Jacek Caban <jacek at 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).

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.