Re: Event loop

[Eric Monsler <eric_monsler radixwireless com>]

Havoc Pennington wrote:
>
(useful advice snipped)
> I'll stay
> out of the "threads vs. processes" debate. ;-)
>
> Havoc

Not being perhaps as wise as Havoc, I want to get into this debate as a
general gadfly.

There was an earlier statement that I strongly disagree with:
G Hasse wrote:
(snip)
> But to do someting like
>
>   while(1)
>   {
>      do_one_thing();
>      do_another_thing();
>      ...
>   }
>
> must be wrong. Here you should use thread *or* processes.


This is completely false as a general design rule.  It may be true, if
the understood context is GTK+ applications, but even then I would say
it is debatable.  Perhaps Goran Hasse meant that context to be
understood, and if so I apologize for overreacting, but I do not want
the out-of-context statement to be taken away by other readers.

A rule is proven false by a counterexample:  I write DSP code for
embedded applications, the main goal of my multitasking design is to use
as FEW tasks as possible.  There are many situations in the embedded
world where the opportunity to use a cheaper, slower processor could
decide the fate of the product.

The loop construct above, IF SUFFICIENT for the specific program goal,
is easily understandable by a new maintainer, incurs no task-switching
overhead (whether of threads or processes), and is I claim a better
design unless do_one_thing() and do_another_thing() are above a certain
complexity and level of interaction.  The right level where they should
be separated is endlessly debatable on a case-by-case basis, but I do
not agree that the level is zero, and that they should always be
separated.

Let us return to the task at hand, which spawned this debate, writing a
large amount of data to file.  If I was doing raw write of application
data, I would consider asynchronous IO as a way to queue a large write
and allow the application to continue.  This leaves the program
relatively simple, and allows the OS to implement the task-switching
required as efficiently as possible.  I am completely unfamiliar with
libpng, it may well be better to use libpng's standard file IO from a
separate task (thread or process), rather than generating file contents
with libpng and writing to file asyncronously, but it is a design
alternative to either threads or processes.


Eric Monsler