On 7/16/06, Mike Hearn <[EMAIL PROTECTED]> wrote:
Well, I think calling CreateThread directly from the context of the hijacked thread would be simpler, though I understand that gets hairy as well if the hijacked thread is holding (say) the loader lock
I'd rather not take the chance of doing anything that messes with the poor thread we're hijacking. Hmm... http://lwn.net/Articles/7577/ makes me think that converting a linux thread to a win32 thread might require initializing the thread's TLS area. We'll look at that a bit.
> Well, kind of. Signals are only delivered when syscalls return, so > they won't work well if the thread you pick to molest happens to > not make any syscalls for a long time. Hm, really? I haven't come across this before ... how then is it possible to debug a program that is sitting in while(1); if SIGSTOP cannot be delivered?
The magic of ptrace().
> Well, if Alexandre thinks that's the way to go, that'd be fine. > I thought those only fired when the thread in question performed > an alertable wait condition (so says > http://msdn.microsoft.com/library/en-us/dllproc/base/queueuserapc.asp ) > so it didn't seem like an obvious way to go. Right but if the thread is suspended then it's waiting, and we could maybe hack it to do an alertable wait. Though doing an alertable wait during a suspend is surely the wrong thing to do in most cases, presumably the server could easily queue an APC itself but not allow other clients to do the same.
That sounds a bit invasive, but if Alexandre prefers it, fine. - Dan
