Open goaaats opened 2 years ago
I never wrote Reloaded.Hooks
with concurrency in mind as past the initial JIT overhead, the time to hook a function is usually negligible (<1ms).
That said, I can imagine at least two possible points of failure:
Assembler
in Utilities
class) being used by multiple threads at once.
ThreadStatic
or use ThreadLocal<T>
so you could have an instance per thread.Semaphore
/Lock
/etc. around it. [I'd actually prefer this in the x86 case as the chance of thread contention is low and I'd prefer to save on limited virtual address space if possible]..Activate()
on the first hook. [The 2nd hook wouldn't register the new function prologue for function because it's not overwritten until you call .Activate()
].This is simply off the top of my head. I didn't look at the code much.
Based on your description, I'd imagine it would probably be the former.
Note: I'm currently on vacation and don't currently have access to a PC most of the time. I'll be home next weekend.
Hi! We recently did a big refactor on our project that introduced parallel component/plugin loads, leading to a lot of hooks being created at the same time. This, on fast machines, seemingly leads to erratic runtime behaviour from reloaded-created hooks, such as:
Sadly, none of our devs are running into this, as it seemingly only happens to users on very fast machines, making it very hard to collect more details about the issue. We already placed a lock around Reloaded hook .ctors in order to have them succeed.
Switching to our MinHook-based backend that we have to troubleshoot issues like this, but don't use in production, resolves the issue. Disposing the misbehaving Reloaded hook, then recreating it at idle when no other hooks are being created, resolves the issue.
Is this a known problem/limitation? Is there anything we could do/log that could help with troubleshooting this?
Thanks!