- GUI - Haskell.org

Re: [GUI] GUIs and events (was: Re: Concurrency)
by Wolfgang Thaller 13 Mar '03

13 Mar '03

Glynn Clements wrote: > But non-thread-safe toolkits still exist. X itself isn't necessarily > thread-safe (thread-safety is optional; AFAIK, XFree86 is thread-safe, > but some other implementations aren't), and toolkits built atop X tend > to be thread-safe only if the underlying X libraries are. ... but I know of no reason why a thread-safe toolkit couldn't be based on a non-threadsafe one. > 1. You need to run a specific sequence of toolkit operations without > any other operations being interleaved. Yes. > Even if the toolkit is > thread-safe, the application itself will still have critical sections > with regard to its use of the toolkit. Granted. I don't mean that the CGA should do the user's work - it should just do the synchronization that falls within it's scope. > And if the application has to do its own locking some of the time, it > may be better to just shift the general problem onto the application. The main reason why I don't like that is the fact that some toolkits are half-threadsafe and require some operations to be done from certain OS threads. Other toolkits already are threadsafe and require hardly any synchronization on the user's part. Writing a CGA backend with proper synchronization can be done IMO, but writing an application that caters to the different synchronization needs of different backends is hard (You'd need to read the docs for GTK, Win32, Carbon/Cocoa, etc. in order to do it properly). > That avoids substantially complicating the toolkit code for a case > which is seldom used (most GUI programs only call the toolkit from one > thread). There seems to be some interest in using Concurrent Haskell for writing GUIs. I fear it will be next to impossible to use Concurrent Haskell in the GUI part of an application if CGA does not automatically do the necessary locking. If people don't have a problem with saying that all CGA calls should come from one (Haskell) thread, then I have no problem with not making the first version of CGA threadsafe. For version 2, we'll know better a) wether we really need it and b) how much work it will be. Cheers, Wolfgang

1 0

Re: [GUI] GUIs and events (was: Re: Concurrency)
by Glynn Clements 13 Mar '03

13 Mar '03

[Originally sent to FFI.] Wolfgang Thaller wrote: > > > 2) CGA implementations should automatically do all necessary > > > synchronization so that the CGA fully supports concurrency even if the > > > backend library does not. > > > > I suspect that this might be a bad idea, and I'm not totally sure that > > it's even possible. I think that it would be better to defer this > > decision until the feasibility can be assessed. > > While different implementations might in some cases be slightly more > complex than just using locks, I don't see why it should be impossible. > After all, thread-safe toolkits are not new. But non-thread-safe toolkits still exist. X itself isn't necessarily thread-safe (thread-safety is optional; AFAIK, XFree86 is thread-safe, but some other implementations aren't), and toolkits built atop X tend to be thread-safe only if the underlying X libraries are. > Do you have any specific problems in mind? 1. You need to run a specific sequence of toolkit operations without any other operations being interleaved. Even if the toolkit is thread-safe, the application itself will still have critical sections with regard to its use of the toolkit. And if the application has to do its own locking some of the time, it may be better to just shift the general problem onto the application. That avoids substantially complicating the toolkit code for a case which is seldom used (most GUI programs only call the toolkit from one thread). 2. Deadlock. You need to specify enough about the locking behaviour that the application at least has the possibility of avoiding deadlock. The most naive approach would be to simply hold a global lock across all toolkit functions. Of course, that would include e.g. XtDispatchEvent, which means that callbacks would be entered with the lock held, so any attempt to call toolkit functions from within a callback would either deadlock or fail. So, that approach won't work. What will work? Do the common toolkits even specify their behaviour in enough detail that it's possible to ensure that any given strategy will work? -- Glynn Clements <glynn.clements(a)virgin.net>

1 0

Re: Concurrency (was: Re: [GUI] Re: events & callbacks)
by Wolfgang Thaller 13 Mar '03

13 Mar '03

Sorry in advance for the long post... Daan Leijen wrote: > Please think a little bit longer before voting a "big NO". If we want > to make > progress we shouldn't rule out a solid and simple solution based on > shaky arguments. My vote remains a big NO for now because I don't consider my arguments shaky. Of course, I'll keep thinking about it, and as soon as I discover the error of my ways, I'll change my vote. If I remain too stubborn, a single "NO" vote isn't a majority for no, so don't worry... ;-) > 2e) All haskell call backs are run in a single OS thread (the "GUI > thread"). Calls to the CGA > can be made at any time from any Haskell thread that run within the > GUI thread. My reservation remains that there is no way for a standard Concurrent Haskell program to control which Haskell threads run in which OS thread. The current proposal for "bound threads" (see ffi(a)haskell.org) will allow some control, but for the sake of simplicity it doesn't support explicitly binding multiple Haskell threads to one OS thread. > 1) What if Haskell automatically decides to run Haskell threads in > some other OS thread? > First, I believe that an automatic system would be a mistake, ... which, if you think that it is a mistake, this mistake has already been made. Threadsafe already exists. > but secondly, such system > will surely provide a forkIO variant that runs the Haskell thread in > the same OS thread. ... which would defeat the purpose of "threadsafe", which was to prevent the FFI from blocking other Haskell threads unpredictably. > However, I don't really want to discuss OS threads/Haskell threads > here, it is > enough to know that this formulation does *not* rule out future GHC's > or future > OS multi threaded systems. ) Do we know this? GHC does not guarantee that multiple Haskell threads are run in a certain OS thread. It most definitely rules out the current version of GHC (with a special configure switch) and everything that was planned for the next version. As I said, there is no defined mapping between Haskell threads and OS threads. So we can't say "... from the same OS thread", because a Haskell programmer currently has no way to say "fork a new Haskell thread in the same OS thread as the current Haskell thread". That leaves us with two options that I can think of: a) Restrict everything to one *Haskell* thread b) Don't restrict anything - require implementations to do proper synchronization or, if the backend requires it, even to channel everything to the right thread. b) is of course more work, and people have had doubts that it is implementable. I'm convinced that it can be implemented, and that it's not too difficult, but of course we can't go ahead with this until all backend implementors are convinced that it's possible. a) probably won't be popular with people who want to experiment with concurrency for GUIs. > You are right that different Haskell threads can interact with each > other in devious > ways by modifying global state... this is called the IO monad :-) > There is no way you can solve this problem in general, and for the GUI > it may involve a lot of overhead. > > *This is the responsibility of the user when using concurrency*. In > your example, > it is a classic multiple writers, single resource pattern. I was thinking of situations where the state is not visible to the user of the CGA. Suppose there was a function like messageBox :: String -> IO () in the CGA. On Win32, this could be implemented by a call to the Win32 MessageBox function. On MacOS, there is no predefined function for that, so the implementation would consist of the following steps: 1) Create a dialog window with the message 2) Show the window & bring it to the front 3) Run the modal event loop 4) Close the window If two Haskell threads (possibly even running in the same OS thread) attempt to call messageBox, then there'll be a race condition here in the Mac version, but not on the Windows version. If we say that that is the application's responsibility, then the application developer would need to know the implementation of the Mac OS backend in order to write a correct program. An average programmer would not forget about locking, test it on Windows, and it would work. On Mac OS, we'd get hard-to-reproduce bugs. > Well, you introduced heavy weight synchronisation that has to be > wrapped around > *every* foreign call to the GUI. No. I'm talking about normal Haskell synchronization primitives. As there's still only one Haskell thread running at one time, they are as lightweight as ever. > Furthermore, you imply that a worker thread should > be run in a different OS thread to keep everything reactive. That will happen automatically in future versions of GHC. If you want a foreign call and a Haskell thread to run in parallel, you need at least two OS threads. Idle callbacks are more inefficient. > However, OS threads are > rather heavy weight and it may take longer to start one than the > processing takes. > In contrast, Haskell threads are extremely light-weight and fast. The RTS pools OS threads. In GHC, I don't expect a complex concurrent GUI program to spawn more than about three OS threads. > I appreciate the work you are doing on supporting OS threads in GHC -- > it is interesting > to see how it will work out. However, for the CGA it is enough to run > in a single OS > thread. The specification should just allow room for use of the CGA in > the context > of multiple OS threads -- but it doesn't have to support all this > automatically as > I think that the issues are more subtle than initially appreciated. > Evolution, not revolution! Of course. I don't insist on requiring CGA implementations to do proper synchronizing, but I think that a) it's not any more difficult than any other problem involving concurrency b) Prohibiting Concurrency and limiting everything to one Haskell thread would be very restrictive c) The middle ground that you proposed, that is to allow multiple Haskell threads to call the CGA as long as they all run in one OS thread, doesn't exist, as a Haskell thread is never guaranteed to run in a certain OS thread. d) Achieving the amount of synchronization & serialization that is automatically provided by a single-threaded RTS is _really simple_, so the number of OS threads should be a non-issue. The question is, do we want to support concurrency or not? Cheers, Wolfgang

1 0

A case of use involving threads
by Nick Name 13 Mar '03

13 Mar '03

I fear that it's not unfrequent, for an IT company, to have to implement systems wich monitor some sort of hardware. It might happen that the hardware has a driver/library tightly coupled with it, written in C. Often, this library will have an event queue, but it could happen that the library has been designed to run in a sort of "mainloop", because it has to send impulses (sort of) to the hardware to let it do a continuous job, with hooks (callbacks) for an eventual UI. Well, in this case, suppose that a customer comes to you and ask an hardware monitor with a GUI. This case is easily rephrased as: make an opengl window and a CGA window run together, each one with its main loop, and manage both from haskell, without directly accessing the opengl event queue (if there is any directly accessible, I don't know). [this has no connection between opengl being a graphics library. An opengl window is just considered as a source of events] Now, if threadsafe exists, there are (if I have understood well what threadsafe is, someone please confirm it to me) zero issues. You run the opengl mainloop as a separate OS thread, and send the results back to haskell. If threadsafe does not exist, what are the alternatives? Would them easily be handled by a clever design of CGA? What sort of design? Can threads be spawned in C and then be used in haskell? Would this be a mess instead? Again, I can do anything more than asking question on this subject, and sorry for the confusion :) Vincenzo

3 2

Re: events & callbacks
by George Russell 13 Mar '03

13 Mar '03

Daan wrote (about whether callbacks are concurrent) > Just for the record: this is *not* true for most (all?) event > based implementations as they are *not* concurrent (at least not > pre-emptively concurrent). Somewhere down, there is an event loop -- > a loop that waits for an event, executes a callback, and loops again. > Even though more events can happen while executing the callback, it > will only propegate into Haskell once the callback returns and the > event loop pops it off the OS event queue. [note: You can achieve more > concurrency in Haskell by using Haskell threads but even than one > has to wait till the callbacks are done or otherwise the runtime system > sits idle while waiting for the next event (as this is a C call).] Well, if the callback model requires you to work in a gaol in which concurrency is banned, it is useless. I rest my case, m'lud. But really, are you serious? Imagine I click button A, which is supposed to start another dialog in which I click button B, and so on. Since it is apparently illegal in GIOs world for button A's callback to include a wait on button B's callback, the only way to do this kind of thing is turn my whole program inside out, rewrite it in continuation-passing-style, and then make button A put the whole continuation on button B's callback. I remember having to do this kind of thing once, back in the days when GHC only allowed continuations to be given to interrupt handlers, and believe me I don't want to do it again. As far as I'm concerned you can forget about any GUI which doesn't allow you to write a function confirm :: String -> IO Bool which puts up a window containing the String and "OK" and "Cancel" buttons, instead making the user put up with the CPS style. confirm :: String -> (Bool -> IO ()) -> IO ()

8 21

Re: [GUI] GUIs and events (was: Re: Concurrency)
by Wolfgang Thaller 13 Mar '03

13 Mar '03

(I accidentally posted this to ffi(a)haskell.org yesterday...) Glynn Clements wrote: > Wolfgang Thaller wrote: > >> 2) CGA implementations should automatically do all necessary >> synchronization so that the CGA fully supports concurrency even if the >> backend library does not. > > I suspect that this might be a bad idea, and I'm not totally sure that > it's even possible. I think that it would be better to defer this > decision until the feasibility can be assessed. While different implementations might in some cases be slightly more complex than just using locks, I don't see why it should be impossible. After all, thread-safe toolkits are not new. Do you have any specific problems in mind? Also, it should be noted that this feature is important: Unless we have this or an equivalent, it will _not_ be possible to use concurrent Haskell for writing GUI programs. Of course, we could still agree that it is a goal, add something like "unless it turns out to be infeasible" and then revisit the issue later. Cheers, Wolfgang

1 0

GUIs and events
by George Russell 13 Mar '03

13 Mar '03

Oh gosh I'm glad we've got a decent debate going on this ... Wolfgang Thaller wrote (snipped) > 1) Callbacks will be executed synchronously. No other events will be > handled until a callback returns. > Rationale: > *) This maps directly to the execution model of all backend toolkits > that I know > *) You can easily get concurrency by calling forkIO, but going the > other way is difficult. I am strongly opposed to this proposal. As a matter of fact this does *not* map directly to the execution model of HTk, in the sense that if I wanted to add such callbacks to HTk I would have to add an extra lock to prevent callbacks running synchronously. However there is a more fundamental objection. I think in general this does not scale. For example initialisation code (1) might occasionally need to put up a window (eg one that says "Can't find configuration file, please enter new path") (2) might, thanks to the common paradigm of doing initialisation using unsafePerformIO, need to be run almost anywhere in the program, including during a callback. The only way of avoiding that is to force the user to adopt a paradigm where no callback may make use of a service which might require an initialisation (or anything else) which itself requires a GUI event. This is highly unpleasant. Also this way of programming is highly unpleasant. For example, if I have a button "Send an insult to Simon.Peyton-Jones(a)microsoft.com" and it wants to put up a window saying "Do you really want to insult Simon Peyton-Jones?" then you need a chain of callbacks. The callback attached to the first button is not allowed to insult Simon PJ itself, instead it has to attach a continuation (containing the insult) to the confirmation button. In general this means continuation-passing-style is going to infect this part of the program. For programs where almost everything is initiated by user action, an awful lot of them is going to have to be written in CPS.

6 7

Re: Events and finalizers
by George Russell 12 Mar '03

12 Mar '03

Nick wrote (snipped) > The true problem here is that once you got an Event, you never uninstall > the callback, even if you just take the first n events and then stop > using the stream. This can be really expensive; do you use finalizers to > uninstall the callback? Well there are two approaches: (1) you provide a more complicated function which in addition to the new event, returns an IO () action which unbinds it. This is what HTk does, in general, though for many simple examples it is of course not required. (2) in many but not all cases it is possible to work out that the stream can be automatically deregistered. For example, as well as finalizers you can also forget the stream when the object is destroyed. Of course this isn't anything particular to do with events; a callback model also has to have a way of deinstalling the callback.

5 13

Events/Finalizers/Streams
by George Russell 11 Mar '03

11 Mar '03

Nick wrote, quoting me, snipped >> For example, will this stream library also subsume CML style events >> (as implemented by me as part of HTk), which allow you to wait on >> multiple events and return when any one of them occurs? > > Well, this is an example wich requires concurrency. "Merge" of events > will be available only on preemptive multithreaded implementation, > unless I am wrong and there is an alternative way (like a "select" > operator). OK, with higher-order events, as invented by John Reppy (CML) and implemented by me in Haskell, you do have a select operator, and you do not need pre-emptive multithreading. (Obviously such things are a good thing anyway, but they are not essential.) So if an Event a is an event carrying a value of type "a", there is a function (+>) :: Event a -> Event a -> Event a which selects either of the two events. There is also another operator (>>>=) :: Event a -> (a -> IO b) -> Event b allowing you to postprocess the result of an event in some way. For example if you have two buttons, a "Yes" button with a click event (yes :: Event ()), and a "No" button with a click event (no :: Event ()) then you can define construct yesOrNo :: Event Bool yesOrNo = (yes >>>= (\ _ -> return True) +> (no >>>= (\ _ -> return False) Then sync yesOrNo will wait for the next button click, and tell you if it was of "Yes" or "No".

1 0

GUIs and events/callbacks.
by George Russell 11 Mar '03

11 Mar '03

I think I've pointed out that the main difference between GIO and HTk is that HTk uses composable events, while GIO, like most other Haskell GUI's (including GTk+hs) use callbacks. Now of course I'm biased, and I prefer events to callbacks, but I appreciate the arguments that have been made that including composable events in a GUI would simply involve adding too much heavy machinery which doesn't have anything to do with graphics. But I think I have a solution to this, which I would like to propose. This is that a GUI standard specify events, but *doesn't* specify that they be composable. Then they would be trivial to implement, and still (in my opinion) be better than callbacks. Also systems like HTk could of course add an extra module which did provide the composition operators. So, in detail, the GUI standard should have a new type Event a which means "Event carrying a value a". To generate for example something like a button click event we could have a function clicked :: Clickable widget => widget -> IO (Event ()) Thus, after this function is called, the returned "event" would happen each time the user clicks the button. A mouse click event might, for example, have type (Event (Int,Int)) giving the co-ordinates of the mouse pointer at the time of the click. To "listen" for events, two functions would be provided: sync :: Event a -> IO a which blocks until the event happens (or returns immediately if a queued occurence of this event has already happened), and setCallBack :: Event a -> (a -> IO ()) -> IO () which added an action to be performed each time the event happens. There are questions to be asked about what happens when you have multiple consumers of the same event. I think it should be guaranteed that when an event happens, only one consumer gets to hear about it, but which does not perhaps need to be specified. (I don't think this is very likely anyway.) Summary ------- Advantages over Composable Events. easier to implement. Advantages over callbacks: can easily be extended to composable events the "sync" operator is more powerful than callbacks (without being particularly hard to implement). For example, I think all or at least most of the call-back-based solutions to the "simple GUI Example" at John Meacham's page http://repetae.net/john/computer/haskell/gui/ contain the following bug: if the user clicks twice very rapidly on the button, the second click will be ignored. In general the click-handling routines can run concurrently, perhaps modifying common shared data, and leading to all sorts of trouble, unless the user uses locks. It seems clear that what is wanted here is sync, not callbacks.

7 17