On 16 July 2012 12:26, Lionel Cons <[email protected]> wrote: > On 16 July 2012 10:11, Cedric Blancher <[email protected]> wrote: >> On 16 July 2012 07:04, Lionel Cons <[email protected]> wrote: >>> On 15 July 2012 23:03, Josh Hurst <[email protected]> wrote: >>>> Again.. >>>> ---------- Forwarded message ---------- >>>> From: Josh Hurst <[email protected]> >>>> Date: Sun, Jul 15, 2012 at 7:39 AM >>>> Subject: sfpoll(): poll for read or write readyness? >>>> To: [email protected] >>>> >>>> >>>> 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 >>> 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. >> >> What kind of function do you need? Which improvements would you make? > > We need a poll-alike for sfio which works and *scales*. > sfpoll() does not work for us: > 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.
Has anyone looked at this wishlist yet? We came across again the 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 _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
