Re: Gnome/Gtk and thread safety

["Dan Maas" <dmaas dcine com>]

> What's a safer alternative to avoiding blocking the UI on slow I/O
> operations or the like? (Hint: main loop async callback based coding
> is not it in most cases...)

What's wrong with callbacks and state machines? I've found async I/O to be
quite effective in my own programs. Yes, writing the state management code
is not always trivial -- but that's because you are dealing *explicitly*
with the added complexity of asynchrony. Multithreading incurs the very same
cost - your program suddenly gains many more states - except you are only
left with *implicit* mechanisms (locking) to cope with it. This is why MT
code is so difficult.

I find writing single-threaded code infinitely safer because I can be
absolutely sure that the state of my program will be consistent from one
event handler invocation to the next. Without this property you are exposed
to the myriad frustrations of debugging MT code...

Were you talking about slow *disk* I/O? In that case I would say that the
POSIX API is flawed - async disk I/O cannot be done using the same nice
semantics as network I/O =(. However, I predict that much of what we use
disk I/O for today will eventually enter the realm of network I/O. e.g. we
won't be reading flat text configuration files from disk, we'll be running
asynchronous queries through gconf. And we won't be loading large images
from disk files, they'll come across a socket bit-by-bit from your shared
media server (my own pet project)......

Dan