> "Karl" == Karl M Hegbloom <[EMAIL PROTECTED]> writes:
Karl> Then, from strategic points within the VM, just as the
Karl> emacsen check for QUIT, you'd check for that signal flag or
Karl> counter, and run the signal handlers from a bottom half of
Karl> some kind. This way,
At Thu, 22 Mar 2001 13:37:29 -0800,
John Harper wrote:
>
> |> I've looked, a little, (and months ago at that) at the LibREP (ala
> |> "sawfish") virtual machine. It's a pretty good indirect threaded VM
> |> that uses techniques pioneered by Forth engines. It utilizes the GCC
> |> ability to
> >> What if, at the C level, you had a signal handler that sets or
> >> increments a flag or counter, stuffs a struct with information
about
> >> the signal's context, then pushes (by "push", I mean "(cons v ls)",
> >> not "(append! ls v)" 'whatever ;-) that struct on a stack...
>
> "Hong" == Hong Zhang <[EMAIL PROTECTED]> writes:
>> What if, at the C level, you had a signal handler that sets or
>> increments a flag or counter, stuffs a struct with information about
>> the signal's context, then pushes (by "push", I mean "(cons v ls)",
>> not "(append!
Hong Zhang writes:
|> I've looked, a little, (and months ago at that) at the LibREP (ala
|> "sawfish") virtual machine. It's a pretty good indirect threaded VM
|> that uses techniques pioneered by Forth engines. It utilizes the GCC
|> ability to take the address of a label to build a jump ta
Here is some of my experience with HotSpot for Linux port.
> I've read, in the glibc info manuals, the the similar situation
> exists in C programming -- you don't want to do a lot inside the
> signal handler; just set a flag and return, then check that flag from
> your main loop, and run a "
I've not researched this at all... perhaps it's a "known" way of
doing things and there is research writing out there already, etc...
I've not even looked at this point. I have about 30 minutes to
outline this and bounce it off of you all this morning. 8-)
I was reading Lincoln D. Stein's
