(Re-send -- only sent to Darryl the first time (oops!))
First, you've pointed out an error in my earlier mail. I definitely
meant `unlock; syscall; lock' in my implementation idea, but got
confused. I mention it inline, but some of the answers above it might
not make sense, so I wanted to clarif
tom fogal wrote:
> Darryl Miles <[EMAIL PROTECTED]> writes:
>> tom fogal wrote:
> It doesn't; I wrote this before I understood your `acquire a
> VG-internal lock at syscall entry' implementation, and didn't come
> back and edit.
>
> I don't see how that's not a scheduler. Each thread essentially
Darryl Miles <[EMAIL PROTECTED]> writes:
> tom fogal wrote:
> > One thing I neglected to think about earlier is how one would do a
> > `Can I still run?' check. There is no notification to a user process
> > when a context switch comes back.
> >
> > Remember that valgrind instruments instructions
tom fogal wrote:
> One thing I neglected to think about earlier is how one would do a
> `Can I still run?' check. There is no notification to a user process
> when a context switch comes back.
>
> Remember that valgrind instruments instructions.
You means a context switch occurred due to timesli
Darryl Miles <[EMAIL PROTECTED]> writes:
> tom fogal wrote:
> > Darryl Miles <[EMAIL PROTECTED]> writes:
> >> Julian Seward wrote:
> >> Then on the return from the system call the current thread checks to see
> >> if it is still allowed to run, if it is not allowed to run it suspends
> >> itself.
