Re: Gnome/Gtk and thread safety

[Maciej Stachowiak <mjs eazel com>]

"Dan Maas" <dmaas dcine com> writes:

> > 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 would put it the other way. MT gives you explicit tools to manage
resource contention, namely locks, condition variables and the
like. Async code forces you to deal with this implicitly by making
sure your code is written such that resources are accessed in safe
ways. I tend to think of resource acquisition as a more useful model
for thinking about large programs than state, because it focuses on
the stuff important to one particular area of code,

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

If you ever succumb to the temptation to invoke the event loop in the
middle of some other operation in async code, you are pretty doomed -
you have to make sure all your code is fully re-entrant and you have
no locking primitives at your disposal. This is very hard.

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

I can't see how a shared media server would work better than loading
images off of local disk. However, local disk was not my main concern.

Mainly I was thinking of network I/O, IPC via sockets, or use of
libraries that don't provide an async interface.

 - Maciej