> The only uses of threads in a full aio application is task
> independence (or interactivity) and process context separation
> Example from GUI side: Suppose your web (http) client is fully
> ported to aio (thus only one thread), if you have two windows and
> one window receives a big complicated html page that needs much CPU
> time to render, this window can block the other one. If you have a
> thread for each window, once the html parser has elapsed its
> timeslice, the other window can continue parsing or displaying its
> (tiny html) page. (In fact you should use two (or more) threads per
> window, as html parsing shouldn't block widget redrawing (like menus
> and toolbars))
It's not strictly necessary to use threads here. At least not with
gtk+. I don't know whether other toolkits are the same.
Anyway with gtk+, you can install "idle callbacks". These are
functions to be called whenever the GUI code has nothing to do. If
you can transform your html parser(s) into idle function(s), then it
won't necessarily disrupt the GUI. You just have to make sure that
the parser yields periodically (returns to gtk+). Since parsers are
loop oriented, this shouldn't be too hard, you just make each call to
the function do 1 iteration of the top level loop.
My traffic generator, mxtraf, works this way. It has a software
oscilliscope (gscope) that graphically displays signals in real time.
At the same time it does lots of IO work to generate synthetic network
traffic. mxtraf is single threaded.
-- Buck
-- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to majordomo@kvack.org. For more info on Linux AIO, > see: http://www.kvack.org/aio/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/