[9fans] Interrupted alarm(2)

[9fans] Interrupted alarm(2)

[Joel Salomon]

I’ve been simulating preemptive multithreading using alarm(2) notes
and lots of stack smashing.  (I’ll have some questions about that
later, if things don’t go smooth.)

Anyhow, my taskfork looks like:
	void
	taskfork(ulong flags)
	{
		long	quantum;

		...

		quantum = alarm(0);	// stop timer and save time left

		...

		// back to our regularly scheduled programming...
		alarm(quantum == 0 ? 1 : quantum);
	}
I included that ugly last line on the off chance that taskfork() is
called with less than a millisecond left and so alarm(0) will return
0.  Is this neccessary, or can alarm(0) not ever return 0?  Would it
be better to write:
		if(quantum)
			alarm(quantum);
		else
			postnote(PNPROC, getpid(), "alarm");
	}

--Joel

Re: [9fans] Interrupted alarm(2)

[Russ Cox]

Use the source, Luke!

>                 // back to our regularly scheduled programming...
>                 alarm(quantum == 0 ? 1 : quantum);
>         }
> I included that ugly last line on the off chance that taskfork() is
> called with less than a millisecond left and so alarm(0) will return
> 0.  Is this neccessary, or can alarm(0) not ever return 0?  Would it
> be better to write:

Certainly I would guess that alarm(0) returning 0 is a perfectly
reasonable thing to do, if the alarm was either imminent or
not scheduled in the first place.

System calls are implemented in /sys/src/9/port/sys*.c, by
functions named sysfoo for the call foo.  In this case sysalarm
just calls procalarm, which is in /sys/src/9/port/alarm.c.
Inspecting that, it is clear that alarm(0) can in fact return 0
in the two cases I just mentioned.  Perhaps more worrying,
it looks like it can also return a negative number if the alarm
time has passed without the alarm actually going off.
And it might not even be the right negative number.

I also don't see anything that keeps one from scheduling
alarms at times in the past, though they will just be treated
as happening as soon as possible (e.g., alarm(-100) looks
like it will cause an alarm to go off at the next clock tick).

It also looks like the delivery of alarms can be stopped by a
single rogue process that can manage to make its p->debug
qlock unlockable and then schedule a quick alarm to get to
the front of the alarm queue.  Making p->debug unlockable is
easy: one way is to arrange that the demand load fault caused
by memmove in case Qnote in procread causes i/o to a file
server that sits on the request.  Then there will be no more
alarms delivered anywhere in the system until that i/o finishes.
This may be less than ideal.

Then again, the whole idea of alarms is broken if you are
depending on them for very much at all, so the fact that the
implementation is also a little broken probably doesn't matter.

Russ