On Thursday 18 August 2011 23:14, Cathey, Jim wrote:
> >I understand what you mean, but poll() loops, despite the misleading
> >name of the central primitive, are not doing any polling at all. poll()
> >works by notification, not by polling (... at least I hope that kernel
> >developers have the good sense to make it so).
>
> The underlying OS details are, hopefully, not actual polling, but the
> paradigm presented to the application program is still effectively
> a poll, just as select is: the paradigm is mother-may-I followed
> by an attempt to actually _do_ what is desired, repeat until done.
> I.e., a poll.
No. The paradigm in "wait until some event happens, then react on it".
The most important feature of select/poll is that they
*wait for something to happen*, and can wait for a set of events,
not just one event.
AIO is sligthly more efficient, but it slightly more complex
to code and understand too.
> (very) pseudo-code of the good main application loop:
>
> while (read(tqfd, &event, sizeof event) == sizeof event)
> switch (event) {
> case keystroke: ...
> case menu_item: ...
> case mouse_click: ...
> case window_refresh: ...
> case timer_exp: ...
> case read_done: ...
> case write_done: ...
> case connection_made: ...
> case connection_died: ...
> case child_exit: ...
> default: ...
> }
> exit(1);
This is nice in theory, but as soon as one of "..." parts
requires blocking, you need to split it into tow (or two dozen)
subparts and include them separately into this gigantic switch.
This becomes unwieldy very quickly. BTW, main loops based on
select/pool are no different: they have absolutely the same problem.
AIO or select loop, async programming is inherently more difficult.
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
