todd.fisher at gmail.com
Sat Apr 12 01:36:53 CEST 2008
I've added my responses inline below:
On Fri, Apr 11, 2008 at 6:49 PM, Chris Brody <chris.brody at gmail.com> wrote:
> > I just wanted to announce a new library I created using libev and
> > It provides 2 interfaces; A C++ interface and a C/Ruby interface for
> > dispatching HTTP requests to a background event loop thread. This could
> > useful for single threaded web applications or desktop applications that
> > need to make multiple concurrent HTTP requests. The project is
> > hosted here: http://evdispatch.rubyforge.org/
> Thanks for sharing the evdispatch project-I only took a quick look
> since I do not really program Ruby. I had been hoping that someone
> would try to integrate libcurl with libev(ent).
> Can you provide some guidance for those who do not program Ruby, i.e.
> how to do the same thing in C++?
Some, I need to work on the documentation for the C++ interface as well as
refine it some more. For now, it's in ev_dispatch.h and ev_http.h
Essentially, you create a EVD::Dispatch object; start it's event loop and
send it EVD::HttpRequest objects via EVD::Dispatch::request method.
Later on you can either poll - using the
response_for/wait_for_response_by_id method or retrieve all - using
the get_next_response method. You can see examples of the 2 different uses
and ext/revdispatch/libdispatch-0.1/test/next_test.cc respectively.
I have been thinking it might be useful to add a 3rd type that would use a
pipe to communicate between the event loop and the main thread. This way,
if for example this was used in creating a proxy server, it would be easier
to stream responses back to the client.
> In addition, I personally like to avoid multi-threading whenever
> possible, which is in line with the philosophy of libevent and really
> possible with libev as well. Have you considered ways to integrate
> reactions to curl responses based on callbacks as well?
I also really like to avoid multi-threading, but I'm afraid given the
limitation of the ruby language (not that it doesn't make up for them in
other ways) it's only possible to take full advantage of libev by running
it's event loop in a separate thread independent of ruby's own scheduling.
At least this is my understanding of how things are within ruby 1.8 today...
ruby 1.9 may change this... But I believe this is fairly common within
graphical applications as well. At least within mozilla IIRC it has a main
thread for doing all of it's drawing and other network operations
are delegated to a secondary thread. I believe the only way I could have
the main thread respond to events on the event loop thread would be to
implement the 3rd type of response handling I mentioned above...
> > libev has been a real pleasure to work with, the interface has been easy
> > follow and understand.
> And easy to embed...
Thanks for the feed back and thanks again for the great library!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libev