Re: [Libbt-devel] role of libevent

[Peter S. <stu...@cd...>]

On Thu, Feb 10, 2005 at 05:02:09PM +0100, Alien wrote:
> > Only reason to use it is the increased performance.
> 
> i sincerely doubt that event would be more performant than using
> select directly, really, in fact with using select directly, you
> should see a slight performance increase.

Well, on reading the libevent page and a few other pages linked from
it, I learned that there are other interfaces available that offer
even better performance than select(). libevent uses them all. Check
out the C10K page for more information. It's about handling thousands
of connections on a server, and while that probably wont be happening
in Torrent clients anytime soon, spending unneccessary time in the
kernel is never useful. :)


On Thu, Feb 10, 2005 at 11:03:43AM -0500, Emil Sit wrote:
> On Thu, 10 February 2005 at 16:45 (+0100), Peter Stuge wrote:
> > libraries. I can certainly live with select() in libbt as for
> > performance, I think it will be good enough. But, on the other
> > hand,
> 
> Performance is not the issue.  The hard problem is how to isolate 
> event-handling code from the details of the library/application so
> that you have a clean and maintainable program.  Much of the work
> that I did was to create clean abstractions. 
> 
> The hard part about making libbt a library is in allowing the I/O
> handling to integrate with the program that it is being linked into.
> If your application uses X, how do you integrate X event loop
> and select/poll/libevent-abstracted I/O handling?
> 
> giFT seems to have the right idea by isolating the I/O into
> a separate process and communicating using RPCs with front-end
> applications.

This brings us to the API/internals topic.. Should libbt work on each
torrent in a separate process, or work on all active torrents in a
libbt process separate from the application, or should we shoehorn
all the IO into the main application process?

I think either libbt process or torrent process is fine, with the
former looking nicer and scaling a lot better.

I don't know enough X to answer your question, but say libbt provides
a fd from pipe() back to the application for notification, would that
be easy enough to check for? If so, libbt can do async however it
wants in it's own process and just send status back through the pipe.


//Peter