Me and Dicebot have just had a quick conversion on IRC about this.
To recap, I'm talking about event loops for windowing.
For an event loop for e.g. socket based systems like Vibe.d it is a different story.

For windowing you have the limitation of having to be on the same thread as the one that created the window. You just can't do anything, drawing a window even processing the event itself can't be done from another thread.

Where as with a socket based event loop you expect other threads to handle it.

So basically you've got to make the event loop implementation be separated out into a per thread and per process aware.
Most importantly if you do e.g. windowing you must activate the per thread event loop.

This is not an easy topic to discuss or solve sadly.

Excuse the naive question rikki, why does the window event loop have to be single threaded ? The question is just to expose the rationale.

Is it to avoid the synchronization overhead to access the window data ? In this case there is indeed a lot of data. Is there another reason ?

In some applications and event types the synchronization overhead is small compared to the benefit of executing tasks in parallel on different cores.

It is indeed none trivial and could be an interresting phd study subject.

On Friday, 6 May 2016 at 12:08:29 UTC, chmike wrote:
> In some applications and event types the synchronization overhead is small compared to the benefit of executing tasks in parallel on different cores.

GUI generates too many messages that are handled too fast - synchronization overhead would be too big. That's not counting concurrency bugs.

On 07/05/2016 12:08 AM, chmike wrote:
> Excuse the naive question rikki, why does the window event loop have to
> be single threaded ? The question is just to expose the rationale.
>
> Is it to avoid the synchronization overhead to access the window data ?
> In this case there is indeed a lot of data. Is there another reason ?
>
> In some applications and event types the synchronization overhead is
> small compared to the benefit of executing tasks in parallel on
> different cores.
>
> It is indeed none trivial and could be an interresting phd study subject.

The window event loop doesn't have to be single threaded, but it is thread limited. Specifically it cannot be on other threads. If you attempt to work with another threads window, it is more or less undefined behavior across the board.

Even with Cocoa (OSX's way for GUI's) is considered thread-unsafe https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html
And that is far higher level then X11 or WinAPI does it.

The tnfox cross-platform toolkit had some solution for per-thread event loops.  I believe this was the demo:

https://github.com/ned14/tnfox/blob/master/TestSuite/TestEventLoops/main.cpp

It seam that the scope of the event loop we are talking should be clarified to avoid confusions.

There is the GUI event loop which is generally single threaded for efficient access to the data structure representing the GUI content. Single thread also simplifies synchronization and make deadlocks impossible. GUI events incoming rates are generally slow because it is human driven. So a single threaded GUI event loop is a very reasonable choice.

The other event loop is for IO and timers. In this case the event rate can be very high and the speed is critical. This is where multithreading can play a useful role and the topic I am interested with.

On unix the OS provides a fast select (epoll, kevent) which tells the user on which fd an event occurred. epoll doesn't cover asynchronous file operations and timer events.
On Windows the OS provides IOCP which support queued operations and the user is notified of the completion.

The boost asio lib adopted the IOCP model. Users queue asynchronous tasks and a callback function that is executed when the task is completed. That is also the model of I/O or timer event loops (e.g. libev, libuv, libevent).

Unfortunately it seam that we don't have much liberty degree if we want an API that can work on Windows and unix. But the unix model can be more efficient.
Here is a blog post reporting that the author could implement a more efficient system than libuv by using epoll directly http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html.

On Monday, 9 May 2016 at 09:14:31 UTC, chmike wrote:
> It seam that the scope of the event loop we are talking should be clarified to avoid confusions.
>
> There is the GUI event loop which is generally single threaded for efficient access to the data structure representing the GUI content. Single thread also simplifies synchronization and make deadlocks impossible. GUI events incoming rates are generally slow because it is human driven. So a single threaded GUI event loop is a very reasonable choice.
>
> The other event loop is for IO and timers. In this case the event rate can be very high and the speed is critical. This is where multithreading can play a useful role and the topic I am interested with.
>
> On unix the OS provides a fast select (epoll, kevent) which tells the user on which fd an event occurred. epoll doesn't cover asynchronous file operations and timer events.
> On Windows the OS provides IOCP which support queued operations and the user is notified of the completion.
>
> The boost asio lib adopted the IOCP model. Users queue asynchronous tasks and a callback function that is executed when the task is completed. That is also the model of I/O or timer event loops (e.g. libev, libuv, libevent).
>
> Unfortunately it seam that we don't have much liberty degree if we want an API that can work on Windows and unix. But the unix model can be more efficient.
> Here is a blog post reporting that the author could implement a more efficient system than libuv by using epoll directly http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html.

Have you looked at http://vibed.org? It is the most successful D library for async IO and it has several backends (some C and some D). It also provides a high-level web framework functionality on top, but it is optional and you can freely use only the low-level stuff.

See also:
http://code.dlang.org/search?q=event
http://code.dlang.org/search?q=async

On Tuesday, 10 May 2016 at 09:58:38 UTC, ZombineDev wrote:
> On Monday, 9 May 2016 at 09:14:31 UTC, chmike wrote:
>> [...]
>
> Have you looked at http://vibed.org? It is the most successful D library for async IO and it has several backends (some C and some D). It also provides a high-level web framework functionality on top, but it is optional and you can freely use only the low-level stuff.
>
> See also:
> http://code.dlang.org/search?q=event
> http://code.dlang.org/search?q=async

Also, AFAIR, the author intends to merge some of the low-level functionality to Phobos.

vibed uses libevent, a C library.

The discussion is regarding a possible pure D equivalent of libevent.
libasync is an interesting proposal but it is apparently slower than libevent. I don't know the current status because vibed improved its performance in the last months.

My initial question is if there is a working group I could join to work on this pure D async library. I'm interested in working on the subject.

On 11/05/2016 1:34 AM, chmike wrote:
> vibed uses libevent, a C library.
>
> The discussion is regarding a possible pure D equivalent of libevent.
> libasync is an interesting proposal but it is apparently slower than
> libevent. I don't know the current status because vibed improved its
> performance in the last months.
>
> My initial question is if there is a working group I could join to work
> on this pure D async library. I'm interested in working on the subject.

Less talk more action.
Aka help out with libasync :)

A working group won't fix things, contributing code will.