On Sat, Jul 21, 2012 at 3:25 PM, Glenn Fowler <g...@research.att.com> wrote:
>
> typedef struct Sfpoll_s
> {
> union
> {
> Sfio_t* sffd;
> int rawfd;
> } fd;
> uint32_t events;
> uint32_t revents;
> size_t matched;
> } Sfpoll_t;
>
> anonymous unions are not portable, so the fd members must be accessed as fd.*
Right... somehow I live too long with C99/C1X and start to forget the
"...olden days..." where K&R and BCPL([1]) ruled the world... :-)
[1]=No, no... I'm not that old... just AmigaOS1.x was BCPL-based and I
had my fun with that when I was much younger... :-)
> since the user must allocate the Sfpoll_t anyway put the matched array
> element there too
> and drop it from the function arg -- the overhead for small #fd callers will
> be negligable
> and large #fd callers will almost always use it
Uhm... the point of the "matched" array was that we don't have to
lineary search the whole |Sfpoll_t|-array for matches. А linear search
over 10 fd is harmless... but imagine a http or irc server with 20000+
fds (e.g. see irc.freenode.net which regulary has issues because the
upper stream limit of 65536 fds is hit (e.g. 60000+ users plus other
fds)) ... in that case a seperate array which returns only the number
of matches is very usefull because often only a handfull is really
"ready" (again the example with the irc server... users type slowly
and while a server may have 50000 active users connected only a
handfull users per second write something. Walking all those 50000
entries to find the 10 who wrote something then becomes...
half-madness).
Or short: Think about the seperate "matched" array as poor-man's
version of a tree ... or "bookmarks" to the important stuff
(technically this was inspired by kpv's |sfpoll()| reordering of fds
to return fds which are "ready" and my current work on poll(1)).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
