On Thu, Aug 24, 2000 at 01:32:10PM -0400, Joshua N Pritikin <[EMAIL PROTECTED]>
wrote:
> > mechanism we could use" that I got on the mailinglist, which becomes
> > increasingly untrue (sigio & friends (like sigtimedwait) are optional
> > posix extensions that get really popular), and the more programs are using
> > it the more "standard" it will become.
>
> Hey, great! I'm all for it. Show me a portable spec and I'll code to
> it!
That's exactly the problem. POSIX has a lot of things that are simply
"optional", and, although SIGIO (the original SIGIO) has been around
for decades, the fact that nobody (except maybe xntpd) used them made
them very unreliable. When xntpd started using SIGIO they found bugs and
only bugsin existing implementations, so the only sane way to to start
using the "portable" spec but limit oneselve to existing and tested
implementations, like in freebsd and linux (and their most recent =
bugfixed, versions).
The "portable spec" you need are the posix realtime extensions (known
as POSIX.4). Using the posix aio_* functions, you can associate a data
value (e.g. a pointer to the watcher) that is delivered with every
signal. (The aio_* functions are, however, very slow on linux currently),
and it also lets you use the sigtimedwait function that is basically the
"get_next_event" function of the kernel.
Every posix.4-supporting system let's you check at runtime wether the aio
fucntionality is available.
Less portable (and maybe only portable to linux and freebsd) is the ioctl
F_SETSIG way.
I don't think there is an online reference to POSIX.4, but the
aio_functions are documented in the glibc manual and the freebsd/linux
nehaviour with respect to fcntl is documented in the fcntl manpage (look
for F_SETSIG).
Maybe uri could contribute the solaris fcntl manpage, and wether solaris
supports posix.4 or not.
> The reason for my (our?) skepticism is that the last time I check
> (admittedly a few years ago), there was just a few scraps of
> documentation about APIs that didn't work very well.
Which was very much true. For example on linux-2.2.x the support has bugs
that seem to be ironed out only on 2.4 (which is not released yet), so,
yes, the situation is better but not really perfect.
> Sure, but if we decide to do something os-specific then I think Linux is
> a good choice. ;-)
Especially if freebsd also support the same API, yes.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
