On 06/05/2016 9:40 PM, chmike wrote:
On Thursday, 5 May 2016 at 09:21:04 UTC, rikki cattermole wrote:
Event loops needs to be thread local not per process.
So many API's such as WinAPI for e.g. GUI's have this requirement in
it that its just not worth fighting over.
I don't understand. Do you mean that these event loops are single
threaded and thus don't allow multi threaded use and parallel event
handling ?
Single threaded model avoids the overhead of synchronization. That would
be another strong argument in favor of single threaded event loop. And
another one is that single threaded application is much easier to get
right than multi threaded applications.
On the other side, WinAPI is old and the actual hardware evolution goes
toward multi core computers and massive true parallelism. At CERN we use
16 core computers. Of course it's good to be backward compatible with
existing APIs but D should be designed to best match the future of
computing I think.
So it seam the question boils down to determine if it's possible to have
the best in both worlds.
I agree that event loops working in isolation is the most simple API
from the user perspective and is the most efficient since
synchronization can be avoided. But worker thread pools has also its
advantages when the app is running on a multicore computer.
Not even close :)
API's such as WinAPI are designed so that an event loop is per thread.
This limitation is quite useful. You can see these limitations in X11 as
well.
E.g. you can't go around drawing in another thread for a window.
For example WinAPI's GetMessage function has "Retrieves a message from
the calling thread's message queue."
https://msdn.microsoft.com/en-nz/library/windows/desktop/ms644936(v=vs.85).aspx
We can't fight stuff like this, its just not possible :)
