Re: Event loop

[Havoc Pennington <hp redhat com>]

Henri Torgemane <henrit yahoo-inc com> writes: 
> 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..

The GLib main loop isn't intended for graphic toolkits in particular -
it's used in the GConf daemon for example. It's excellent for writing
daemons; daemons are in general event-driven in basically the same way
a GUI app is. The main loop is quite efficient and general-purpose.

That said you can't always escape threads or processes. The reason you
can sometimes be forced to use them is that some operations are in
practice too hard to make nonblocking. Some calculations for example
can't be easily parceled into small chunks, some kinds of I/O don't
let you easily avoid blocking, or maybe you're using a preexisting
library that only has blocking calls, and you don't want to
reimplement an asynchronous library with the same functionality. 

Any method of making things asynchronous can be quite difficult to get
right; it's a pretty hard problem.

Havoc