On Monday, 16 May 2016 at 17:08:32 UTC, chmike wrote:
- There is no need to preallocate a buffer for all input
channels that can stay idle for a long time. This doesn't scale
well to million connections.
Can you request one byte and then read what was buffered?
On Tuesday, 10 May 2016 at 13:34:36 UTC, 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
On Tuesday, 10 May 2016 at 13:34:36 UTC, 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
On Tuesday, 10 May 2016 at 13:34:36 UTC, chmike wrote:
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.
Considering libasync is only native D async library supported by
vibe.d right now, focusing
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
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
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
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
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
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
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
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
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
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
On 06/05/2016 11:21 PM, Dicebot 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.
It is implementation
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.
It is implementation detail. You can have global event loop and
On Thursday, 5 May 2016 at 08:19:26 UTC, chmike wrote:
At the bottom of the wiki page there is an innocent question
regarding TLS which is quite devastating. A worker thread pool
system would not support affinity between threads and callback
context. Unfortunately, D relies on Thread Local
On Thursday, 5 May 2016 at 08:19:26 UTC, chmike wrote:
At the bottom of the wiki page there is an innocent question
regarding TLS which is quite devastating. A worker thread pool
system would not support affinity between threads and callback
context. Unfortunately, D relies on Thread Local
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
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
On Thursday, 5 May 2016 at 08:19:26 UTC, chmike wrote:
Hello I have seen the wiki page
https://wiki.dlang.org/Event_system and would like to know the
current status. Is there a working group for this subject ?
This is a topic I'm interested in and did some modest work on
some years ago.
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 would like to add that the switchable TLS is only a half backed
solution. It would't work in a multi core context where threads
are truly executing in parallel. Two such threads might get the
same TLS context which would invalidate its implicit predicate.
Another strategy would be to forbit
Hello I have seen the wiki page
https://wiki.dlang.org/Event_system and would like to know the
current status. Is there a working group for this subject ? This
is a topic I'm interested in and did some modest work on some
years ago.
At the bottom of the wiki page there is an innocent
24 matches
Mail list logo
