Date: Mon, 8 Apr 1996 15:05:09 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: louie@TransSys.COM, terry@lambert.org, hackers@FreeBSD.org, jkh@time.cdrom.com, msmith@atrad.adelaide.edu.au, roell@blah.a.isar.de, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604082205.PAA03097@phaeton.artisoft.com> In-Reply-To: <199604081004.UAA25433@godzilla.zeta.org.au> from "Bruce Evans" at Apr 8, 96 08:04:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >What a SIGIO based scheme does is interrupt whatever computation is > >going on, read the packet from the socket, timestamp it, and put it > >into a queue to be processed at some later time. Once you've noted > >the arrive time, the time criticality is gone, and you can process it > >at your leisure. > > This doesn't help much if there are `M' higher priority hoggish > interrupt handlers that run before the packet's interrupt handler, > and `N' other hog processes in the kernel or in user code that run > before the SIGIO is delivered. Exactly. You can not make Realtime guarantess on a non-Realtime system, and you can't fudge it to pretend you are doing this, and have it work reliably. It's entirely possible that your client command list is going to take a lot of crunching without kernel space calls, and since signals are only handled on call return, you're going to be screwed even with SIGIO. [ ... ] > >Of course, some of us are really weird this way. That how we end up > >with PLL models of the computer's clock in the kernel. > > Some of us wouldn't settle for an offset of 7 digits of nanoseconds :-). 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604082205.PAA03097>