On 12 August 2013 23:17, Lionel Cons <[email protected]> wrote: > 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.
Anyone? Glenn? This has become a serious showstopper for us. Lionel _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
