On resources and KTHREAD
jacek at codeweavers.com
Thu Feb 21 07:52:34 CST 2019
On 2/1/19 4:44 AM, Zebediah Figura wrote:
> As the last leg of my journey (for now) implementing Windows' thousand
> synchronization objects, I arrive at ERESOURCE. Unlike the last three
> forms of mutex, these can be recursively acquired, and so it's
> necessary to keep track of who is holding them. I have a complete
> implementation that passes its own tests, but only with
> KeGetCurrentThread() stubbed to return the TID.
As mentioned in bug, if it's the only thing preventing you from sending
it, using KeGetCurrentThreadId() in ERESOURCE until we have
KeGetCurrentThread() doesn't seem too bad.
> A proper implementation of KeGetCurrentThread() is already required by
> some drivers (bug 45844). What would be necessary to implement this
> function in an acceptable way? If simply returning the TID isn't
> enough (and I believe this approach has been rejected before), how
> much of the structure need we correctly implement? How can we find out
> what that structure is, undocumented as it is? (For a slightly more
> concrete question: is  a legally safe source?)
I don't know about how much of the actual struct do we need, but even
being able to reference the object by pointer would be enough for some
applications (and for your use case, I guess). I recently looked at
ObReferenceObjectByHandle (which is needed by MRAC anti-cheat as well we
others, according to bugzilla). It's not strictly needed for
KeGetCurrentThread(), but having it implemented for threads would take
care of object lifetime and HANDLE to object pointer mapping. I have a
proof of concept code for ObReferenceObjectByHandle(). The idea there is
to do actual handles to client object pointer mapping in wineserver.
Server also notifies device manager when the underlying object is
released, so it may free its object.
More information about the wine-devel