On Tue, 24 May 2011 04:50:10 +0900, jdrewsen <jdrew...@nospam.com> wrote:
Den 23-05-2011 21:02, Masahiro Nakagawa skrev:
On Wed, 18 May 2011 20:07:01 +0900, Jonas Drewsen <jdrew...@nospam.com>
wrote:
On 18/05/11 10.09, Johannes Pfau wrote:
jdrewsen wrote:
But I would rather stop here feature wise and wrap
this thing up. I would like to focus my efforts on a candidate for
std.net.event/reactor/proactor module.
Have you already started working on std.net.event? Do you plan to base
that on libev / libevent?
I'll finish the curl wrapper before starting on it.
I have had a look at libev/event before and they are very nice libs.
But I think I'll have to implement it from scratch for two reasons:
1, AFAIK we cannot include code in std phobos that is not boost
licensed or a license as liberal. libev for example requires you to
distribute the license with your software.
2, It introduces a dependency to an external project in phobos.
Currently no dependencies are present. This makes phobos very easy to
install and use out of the box.
The optimal solution to these problems from my point of view would be
to get that "much discussed" package tool in place soon (CPAN,apt
alike).
Heck, now I think about it maybe I should do that before any std.net
stuff. Let's see how the wind blows - many interesting projects :)
Good!
Last year, I tried to implement std.event. In Windows, using IOCP with
Overlapped-IO for proactor.
Others, IO multiplexing with worker-thread for proactor emulation.
But Johannes already started implementing event module using libev,
so I deleted this task from my tasks.
If you have any code for inspiration or that could be used as a base I
would very much like to see/use it. Especially if it is under Boost
license.
My old design is based on Boost/Asio. After I rewrote std.socket(including
other utilities such as DNS, IPAddresses), I stopped implementing task.
I would like to create reactor initially and proceed to build the
proactor on top of that (not on top for windows and IOCP of course).
Reactor and proactor designs each have their forces and therefore I do
not think targeting a proactor only design is the way to go.
I agree. General library should provides two approaches.
My main purpose is high-performance RPC. In such cases,
Proactor is better(Java's Netty provides good abstraction APIs).
