Lionel Cons
2013-08-12 21:17:59 UTC
Again..
---------- Forwarded message ----------
From: Josh Hurst <joshhurst at gmail.com>
Date: Sun, Jul 15, 2012 at 7:39 AM
Subject: sfpoll(): poll for read or write readyness?
To: ast-developers at research.att.com
If sfpoll() calls a discipline with SF_DPOLL, how can I figure out
whether the caller of sfpoll() wants to check if the stream is ready
for reading or writing?
I'd avoid sfpoll() and write an own function. For better or worse---------- Forwarded message ----------
From: Josh Hurst <joshhurst at gmail.com>
Date: Sun, Jul 15, 2012 at 7:39 AM
Subject: sfpoll(): poll for read or write readyness?
To: ast-developers at research.att.com
If sfpoll() calls a discipline with SF_DPOLL, how can I figure out
whether the caller of sfpoll() wants to check if the stream is ready
for reading or writing?
sfpoll() is IMO a useless piece of garbage. We've tried very hard to
get used to it but i turned out that it is not suited for normal
applications beyond ksh.
1. It uses malloc(). This should be avoided in an event loop. It's
even crazy to do so in an event loop. That's why alloca() was
invented.
2. sfpoll() has no way to distinguish whether a stream is ready for
reading, writing, an error occurred, a hangup was received, an out of
band event arrived or something else happened. poll(2) does that all.
3. sfpoll() supports sfio disciplines, but has no extra flags that the
disciplines can return. For example for a poll(2)-alike we'd like to
have POLL_USR1IN, POLL_USR1OUT, POLL_USR1HUP, POLL_USR1ERR,
POLL_USR2IN, POLL_USR2OUT, POLL_USR2HUP, POLL_USR2ERR, ... as set of
flags which can be returned by disciplines (like SIGUSR1/SIGUSR2 were
added as signals specifically for application usage)
4. sfpoll() reorders the fds. This sounds like a nice feature in the
1970' with three streams but becomes a nightmare if your applications
juggles 15000 or more streams at the same time. Each time sfpoll()
returns I have to do a linear search for each fd and then you have to
do a lookup for the flags I stored elsewhere. poll(2) makes it better
because I know which index number by fds of special interest are and I
can define myself a specific lookup order.
5. On some platforms sfpoll() calls select() and select() calls then
poll(). Why not call poll() directly?
What we want is a sfpoll2() function which works exactly like POSIX
poll(), which takes a pointer to an array of struct pollfd-like
structures, with flags like POLLHUP, POLLERR, POLLRDNORM, POLLRDBAND,
same for write, POLL_USR1IN, POLL_USR1OUT, POLL_USR1HUP, POLL_USR1ERR,
POLL_USR2IN, POLL_USR2OUT, POLL_USR2HUP, POLL_USR2ERR, a timeout value
and maybe (optional) taking a signal mask like ppoll() on Linux does.
So far, that's my xmas wishlist. For sfio and polling.
limitation of sfio's polling system; its painful to use. IMO a poll(2)
inspired sfpoll2() with the features listed above would be a welcome
addition.
Lionel