Jeff Clites <[EMAIL PROTECTED]> wrote:

> But if the "event dispatch" thread is setting some flag for the target
> thread to detect, it's going to need to lock (or something similar) to
> make sure that the value of this flag is visible to other threads.

Yep, that's true. The event thread puts an event into the interpreters
task queue. This is done by locking the task queue, inserting the entry
and unlocking it. This sequence ensures, that the queue entry with the
event hanging off it, will be visible to the target interpreter.

> ... So that could mean a
> lock inside of every invoke....

No not AFAIK. Inserting the event into the task queue should already be
enough, to make it visble for the target interpreter.

> .... So
> now we are probably quadratic with the size of the segment. (Patching N
> locations leads to N times where we un-patch all N locations.)

I would say O(2*N) max.

Yet another idea: The event thread could set some piece of memory (e.g.
the JITed instruction stream) to PROT_NONE and catch the SIGSEGV. Some
read/write barrier schemes for inkremental GC are using this approach.

> JEff

leo

Reply via email to