From: koral <ko...@ma...> - 2014-11-03 12:40:20
|
> So it seems that you want to lookup the type of a file in parallel. If Gtk+ would allow you to arbitrarily delay a signal handler (so that you wouldn’t even have to spawn a new thread during the signal handler) then the GUI would be unresponsive until all these threads have returned a result. If determining the mime type means opening the file and this file sits on a network that is down then you need a timeout and your GUI would be unresponsive until this timeout has run out. Regarding the example of mimeTypePolicyDecisionRequested, the final decision is essentially whether to render or download a file. Why should the main GUI loop wait for this decision ? In other words, using my code example, why should thread A wait for thread B to end ? It kind of defeats the purpose of having thread B != thread A. It seems to me that this constraint imposed by gtk is unnecessarily too strong. > In a nutshell: a good (responsive) GUI is built by always returning immediately form an event; a true parallel event implementation would not make it any easier to fulfilling this goal. My concern is more about code separation/isolation rather than concurrency, notably I'd like to run the UI thread and the signal handlers in distinct monad stacks, and concurrency seemed a good way to achieve that. If you have an idea on how to do it differently, I'm all ears. -- koral |