Concurrency (was: Re: [GUI] Re: events & callbacks)

[Axel Simon]

On Wed, Mar 12, 2003 at 10:02:35AM +0100, Nick Name wrote:
> On Wed, 12 Mar 2003 08:22:46 +0000
> Axel Simon <A.Simon@ukc.ac.uk> wrote:
> 
> > 
> >   Yes, please. You got my vote for that. No preemptive concurrency
> >   with GUIs.
> 
> Can you explain a bit more what this is going to mean? I see many
> advantages in multithreading, and there's people wich works with
> multithreading in C and succeeds.
 Don't get me wrong. OS thread support in GHC is good and CGA should cope 
with that. But I would like to have just one thread talking to the GUI.

 Concurrency is surely need in GUI applications. I think we talk about
non-preemptive and preemptive. I know that Gtk is (and will stay)  
non-preemptive. As such there is no way of writing a preemptive CGA
backend based on Gtk. My vote is therefore mostly Gtk-centric and not very
objective, but...

> --- how to play the devil's advocate with the os threads matter :) ---
> 
> Will we in the 2005, with hardware thread support in baby monitors and
> coffee machines, go to software engineers and tell them "you will do
> everything in one OS thread, but this functional language is really
> cool" ? 
 ...everytime I faced real preemptive concurrency so far, I tried to
restrict this behaviour to a small code fraction and abstract away from
all the synchronization issues. I always fear that I miss something and
the whole system eventually falls over. So yes, one OS thread for the GUI,
one for the database, one for each socket,... . I think this is not a
restriction but the natural approach.

Once we have OS threads, attaching something to the idle handler of
(Gtk's) event loop is not necessary anymore since the Haskell RTS will
continue to run. But every call to Gtk (or whatever library) will be
channeled through this one thread. Is this a restriction?

Axel.