Re: Event loop

Ok ok, I probably shouldn't help keeping this thread alive, but I'm wondering
something, and I'm sure pretty you guys can enlighten me:

Glib offers a pretty cool loop to deal with events, including stuff to
monitor IO activity. Now if I want to write a server application that does a
whole lot of network processing, it's kinda tempting to make all my IO
asynchronous, plug them to Glib and have everything work in one big happy

My question is: Is there any drawback with that approach? Would I be better
off forking or spawning threads to deal with pieces of the network logic
separately (which is sort of the "traditional" unix server design) ?
I'm under the impression using Glib that way is efficient since it doesn't
have any of the overhead threading of forking would incur..
Everything gets processed sequentially, but it's exactly what would happen if
things were threaded anyway (assuming only one processor in the box)

On the other side, Glib was written to be used with a graphic toolkit, not
with a network intensive program, and while its implementation seems to be
pretty efficient, one can wonder if it's the right tool for the job. Also I
haven't really heard of any other server out there based on Glib..

What do you guys think?


G Hasse wrote:

On Mon, 13 Nov 2000, Eric Monsler wrote:

Havoc Pennington wrote:

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


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:
But to do someting like


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

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

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       Fax: 08-6949280
Sickla Alle 7, 1tr                              Mob: 070-5530148

gtk-app-devel-list mailing list
gtk-app-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]