Nick Name wrote:

On Wed, 12 Mar 2003 19:05:51 +0100 Wolfgang Thaller wrote:

...

1a) Event loops may be nested, i.e. a callback, or (if proposal 2 is also accepted), any other IO action, may call a CGA function that runs another event loop, e.g. for handling an application-modal dialog (the main event loop won't handle events during that time).

I am sorry to make you repeat yourself, but I wish to understand it well. Event loops may be nested

... in order to allow application-modal dialogs to be created as easily as with Win32, Carbon, GTK, etc.

, but: there will be a way to avoid that. Is this what you are saying?

I haven't said that. But it's probably a good idea. However, I think this is a (partly) independent issue, so those details should be discussed separately (as point 3, for example). I was only saying that we should do without concurrency by default (unless somebody wants to use concurrency). It's obvious that all kinds of applications are possible that way (GTK, Win32, Carbon, Cocoa, Swing and many more all work without concurrency). The discussion about how to do it exactly, how to handle modal dialogs and other things like that should probably be the next discussion topic.

There needs to be a way to make both a callback and its parent window handle events simultaneously, even in non-preemptive environments, without forkIO.

Agreed (at least if I understood you correctly). Here's a first guess on how things could be done. This is not a real proposal yet, it's just a first guess, heavily influenced by Apple's APIs: *) non-modal windows: If a callback wants to open a non-modal window, it should just open the window, attach some callbacks to the window and return to the main event loop. No special issues here. *) application-modal dialogs: For application-modal windows, at least Win32 and Apple's APIs (don't know about GTK and others) provide a function that runs a nested event loop. For expose events and other events that still have to be handled when a modal dialog is active, this nested event loop invokes the appropriate callbacks. *) window-modal dialogs: We should also support window-modal dialogs for those platforms that support it --- I only know that they are supported on Mac OS X, I'm not sure if users of other platforms would even want them. If a backend doesn't support window-modal dialogs, it can treat them as application-modal instead. The above things are just first ideas. The main point is, who agrees/disagrees that (I'm just rephrasing my original two points again): 1) We should adopt a callback scheme that does not require concurrency 2) CGA implementations should automatically do all necessary synchronization so that the CGA fully supports concurrency even if the backend library does not. (2b) We should be careful to ensure that CGA functions can be invoked from a "background" thread while the "main" thread is waiting for events (means additional work, but it is probably necessary if we want to fully use concurrency). Cheers, Wolfgang

On Wed, 12 Mar 2003 23:46:57 +0100 Wolfgang Thaller wrote:

...

, but: there will be a way to avoid that. Is this what you are saying?

I haven't said that. But it's probably a good idea. However, I think this is a (partly) independent issue, so those details should be discussed separately (as point 3, for example).

I am by no means useful in a discussion about strategies in multithreading. I rephrase my wish, and leave it here for the mission statement. GUI libraries wich make the application hang when a dialog is created are a bad idea. We need to have a way, even in hugs, to control the events that are to be sent to the underlying parent window when a dialog is created. Vincenzo

*) non-modal windows: If a callback wants to open a non-modal window, it should just open the window, attach some callbacks to the window and return to the main event loop. No special issues here.

*) application-modal dialogs: For application-modal windows, at least Win32 and Apple's APIs (don't know about GTK and others) provide a function that runs a nested event loop. For expose events and other events that still have to be handled when a modal dialog is active, this nested event loop invokes the appropriate callbacks. For information: yes, same thing in Gtk. You just call mainLoop again (or runDialog) which lets the global event loop run. The underlying application window would still emit redraw/expose events but no buttons could be pressed since it cannot get the input focus as long as the modal

On Wed, Mar 12, 2003 at 11:46:57PM +0100, Wolfgang Thaller wrote: dialog is open. I guess this is the same in all three backends. [..]

1) We should adopt a callback scheme that does not require concurrency 2) CGA implementations should automatically do all necessary synchronization so that the CGA fully supports concurrency even if the backend library does not. (2b) We should be careful to ensure that CGA functions can be invoked from a "background" thread while the "main" thread is waiting for events (means additional work, but it is probably necessary if we want to fully use concurrency). Glynn oposed to this, he said it could be very difficult or even impossible. I thought this would come for free with the FFI if we wrap all GUI calls with

foreign ccall thread "GUI" blah... which means all calls are done from a single OS thread called "GUI". I suspect this didn't wind up in the FFI, or did it? Axel.