Hi,
Yes I think you’re right. Indeed the machine has one
timer interrupt and it’s enough for the kernel to demultiplex
it over many processes who each can have different alarm
requirments.
Thx.
> On May 2, 2015, at 8:06 AM, erik quanstrom wrote:
>
>> I’m not sure I understand your proposal.
>>
won't you need some kind of flow control in this? just hammering
notes onto a process constantly might prevent that process from
doing any progress and even stack overflow as signal handlers
are reentrant on unix/ape. i remember that these timer
signals where handled specially in the linux kernel w
> I’m not sure I understand your proposal.
>
> But looking more at the code I need to port, an interpreter, I think
> the main issue is that the interpreter relies on sigvtalarm as
> a way to preempt the interpreted program while allowing
> the user program to use only sigalarm. So more generally
one way to solve this would be to fork as many procs as there are
timers; each would sleep the length of its timer value and then
postnote an identifying artificial note (vtalarm, fooalarm, etc.) to
the parent process. the parent process then interprets the artificial
note as a particular type of
Hi,
I’m not sure I understand your proposal.
But looking more at the code I need to port, an interpreter, I think
the main issue is that the interpreter relies on sigvtalarm as
a way to preempt the interpreted program while allowing
the user program to use only sigalarm. So more generally
the pro
