Re: Event loop

[G Hasse <gh raditex se>]

On Mon, 13 Nov 2000, Eric Monsler wrote:

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

I *know* why you wisely do so. :-(

> 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.

Sigh... Can't we make a list of all extreme environment to progam
in and classify which of them should be debateble in
gtk-app-devel-list gnome org  ;-)

> 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.

Does anyone have a list of all mail-lists or even all net-news groups
around???

> 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.

ISBN 0-201-56317-7 is a good startingpoint.

G Hasse

----------------------------------------------------------------
Göran Hasse            email: gh raditex se     Tel: 08-6949270
Raditex AB             http://www.raditex.se    Fax: 08-6949280
Sickla Alle 7, 1tr                              Mob: 070-5530148
131 34  NACKA, SWEDEN