Gordon Henriksen <[EMAIL PROTECTED]> wrote:Leopold Toetsch wrote:
2) Patch the native opcodes at these places with e.g. int3
I don't think that bytecode-modifying versions should fly; they're not threadsafe,
Why? The bytecode is patched by a different thread *if* an event is due (which in CPU cycles is rare). And I don't see a thread safety problem. The (possibly different) CPU reads an opcode and runs it. Somewhere in the meantime, the opcode at that memory position changes to the byte sequence 0xCC (on intel: int3 ) one byte changes, the CPU executes the trap or not (or course changing that memory position is assumed to be atomic, which AFAIK works on i386) - but next time in the loop the trap is honored.
Where in the stream would we patch? If not in a loop, you may never hit the single patched location again, but still might not end for a very long time....
If we are patching all locations with branches and such, in large bytecode this could take a long time, and the executing thread might outrun the "patching" thread. Also, once the handler is entered we'd have to fix all of patched locations, which again could be time-consuming for large bytecode.
It could work, but seems problematic.
JEff
