Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I would have to say no, with a caveat. Event driven frameworks that revolve around shared state, such as a UI, <em>should</em> be single threaded. Event driven frameworks that revolve around notifications, such mechanical monitoring(e.g. letting you know when the pressure in a pipe is too high), could be single threaded, but might be more appropriate to be multi threaded.</p> <p>It is certainly possible to build a multi threaded UI framework, and I have done so myself. In the end I converted it to be single threaded. Part of the reason does fall under what Charlie said about "it's too hard". The problem was that with a multi-threaded UI framework, it wasn't just <em>me</em> that had to deal with the threading, but anyone that used the UI. The core was certainly thread safe, but then anyone that wrote a control had to make <em>that</em> thread safe as well. Nevermind that when making multiple changes to the UI, you had to notify the core that you were doing so so you didn't get partial updates. Since a user is generally a pretty slow thing, any performance gain was really negligible, and could be worked around with an asynchronous call if necessary for specific cases. Single threading is actually the appropriate model here.</p> <p>On the other hand, in a model where there isn't(or isn't much) shared state, a multi threaded model makes eminent sense. There's no reason for one event(the reactor is on fire) to be delayed for the 30 seconds it takes for your query(Bob the operator just clocked out) to timeout because some yahoo in operations left the punch_card table locked.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload