Date: Sun, 23 Jan 2000 20:08:07 -0600 From: Dan Nelson <dnelson@emsphone.com> To: Mikhail Teterin <mi@kot.ne.mediaone.net> Cc: Jason Evans <jasone@canonware.com>, David Schwartz <davids@webmaster.com>, bde@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: kern/13644 Message-ID: <20000123200807.A19917@dan.emsphone.com> In-Reply-To: <200001240126.UAA44772@rtfm.newton>; from "Mikhail Teterin" on Sun Jan 23 20:26:15 GMT 2000 References: <20000123121055.F27689@sturm.canonware.com> <200001240126.UAA44772@rtfm.newton>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jan 23), Mikhail Teterin said: > =FreeBSD is clearly not capable of hard real-time. If I > =remember correctly, neither are any of the operating systems from > =which you quoted man pages. That makes *all* of those man pages > =inaccurate. > > In other words, we found a flow in the most (all?) Unix implementations? > Including FreeBSD. Alright. If you want to call it a flaw, then yes. The kernel always has priority over user processes. If an ethernet packet comes in, a character is received over a serial port, or a disk wants to return a block of data requested by the system, your user process *will* stop and the kernel will processes the interrupt. If that interrupt takes a while, a select() or poll() may very well return later than the timeout specified. Apart from writing your own kernel module, blocking all interrupts, and buzz-looping on a timer variable, there's not much you can do about it under Unix. And I'll not even mention what happens to this when you start swapping. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000123200807.A19917>