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
On Jan 17, 2004, at 12:33 PM, Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
Ops that can leave the code segment have to explicitely check for
events.
But if the "event dispatch" thread is setting some flag for th
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Jan 17, 2004, at 2:51 AM, Leopold Toetsch wrote:
> What I meant was, _every_ backward branch (etc.) in the bytecode, or
> just one location that we thought would execute "soon". (But you
> implicitly answered this, below.)
Every backward branch. Guessin
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
>> Ops that can leave the code segment have to explicitely check for=20
>> events.
> Then no need to patch invoke*.
Yep, that's true. I'm waiting for the ops-file hints, then that can be
On Jan 17, 2004, at 2:51 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
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
Same as with prederefed run cores: backward branc
On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
What if control leaves the current code segment before you finish
patching it?
Ops that can leave the code segment have to explicitely check for
events.
Then no need to patch invoke*.
I
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> What if control leaves the current code segment before you finish=20
> patching it? If an event is being delivered from another thread, this is=20=
Ops, that can leave the code segment have to explicitely check for
events.
> Gordon Henriksen
leo
On Saturday, January 17, 2004, at 05:51 , Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
... Also, once the handler is entered we'd have to fix all of patched
locations, which again could be time-consuming for large bytecode.
Please remember: only the current code segment has to b
On Saturday, January 17, 2004, at 05:53 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
Other threads than the target could be executing the same chunk of
JITted code at the same time.
No. JITed (and prederefed) code is thread-specific, because register
addresses are conver
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Other threads than the target could be executing the same chunk
> of JITted code at the same time.
No. JITed (and prederefed) code is thread-specific, because register
addresses are converted to absolute memory locations.
leo
Jeff Clites <[EMAIL PROTECTED]> wrote:
> 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
Same as with prederefed run cores: backward branches, invoke*
> If we are patching all location
On Jan 16, 2004, at 1:20 PM, Leopold Toetsch wrote:
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 d
Leopold Toetsch wrote:
> 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 positi
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
Michal Wallace <[EMAIL PROTECTED]> wrote:
> On Fri, 16 Jan 2004, Dan Sugalski wrote:
>> interrupts. Even if they aren't doing any IO at all they're still
>> potentially watching for keyboard (or other OS-initiated)
>> breaks/interrupts.
> I see your point. In python if you press ^C, it should
> ra
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:38 AM +0100 1/16/04, Leopold Toetsch wrote:
>>Event handling currently works for all run cores[1] except JIT.
> What I'd planned for with events is a bit less responsive than the
> system you've put together for the non-JIT case, and I think it'll be
Michal,
> But rather than always monitoring for that, I'd want
> to register a listener and then have parrot handle the
> polling for me.
This is precisely what's being discussed.
> This is probably a dumb question but: what if signals
> threw exceptions instead?
I'd hope that the event handle
On Fri, 16 Jan 2004, Dan Sugalski wrote:
> >I don't understand that part. Why the compiler?
>
> Because we don't have the sort of control of the async environment
> that hardware does to deal with interrupts.
>
> And, realistically, all code has to deal with the possibility of
> interrupts. Even
Leopold Toetsch wrote:
> Event handling currently works for all run cores[1] except JIT.
>
> The JIT core can't use the schemes described below, but we could:
> 2) Patch the native opcodes at these places with e.g. int3 (SIG_TRAP,
> debugger hook) cpu instruction and catch the trap. Running the
At 1:45 PM -0500 1/16/04, Michal Wallace wrote:
On Fri, 16 Jan 2004, Dan Sugalski wrote:
2) Those that explicitly check for events
...
Ops like spin_in_event_loop (or whatever we call it) or checkevent is
in category two. They check events because, well, that's what they're
supposed to do. C
On Fri, 16 Jan 2004, Dan Sugalski wrote:
> 2) Those that explicitly check for events
...
> Ops like spin_in_event_loop (or whatever we call it) or checkevent is
> in category two. They check events because, well, that's what they're
> supposed to do. Compilers should emit these with some frequen
At 11:38 AM +0100 1/16/04, Leopold Toetsch wrote:
Event handling currently works for all run cores[1] except JIT.
The JIT core can't use the schemes described below, but we could:
1) explicitely insert checks, if events are to be handled
1a) everywhere or
1b) in places like described below under [
22 matches
Mail list logo
