From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 12 Dec 2006 23:13:07 -0500 From: "Russ Cox" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Interrupted alarm(2) In-Reply-To: <68313859d562920ef34e99b7dc1a4046@plan9.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <68313859d562920ef34e99b7dc1a4046@plan9.jp> Topicbox-Message-UUID: f39cccaa-ead1-11e9-9d60-3106f5b1d025 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