Re: [Libbt-devel] role of libevent

[Alien <ali...@us...>]

Op vrijdag 11 februari 2005 01:34, schreef Elliott Mitchell:
> >From: Alien <ali...@us...>
> >
> > Op donderdag 10 februari 2005 05:38, schreef Elliott Mitchell:
> > > Does not include Windows though...
> >
> > i couldn't care less about that
>
> Despite the annoyance they do exist. To truely takeover the world it is
> best not to argue with the end users.
>
> I'm suggesting glib as it is capable of encapsulating all IO in a
> cross-platform manner. Also has a nice object system written in C already
> put together.

but not as efficient as doing it ourselves in a lowleve manner, which is th=
e=20
subtitle of this project, and will be our ticket into being standard distro=
=20
material.

> >From: Peter Stuge <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. :)
>
> glib looks poll() oriented, libcurl is definitely select() oriented
> (wonder how they claim to work on EvilOS?). It appears that select() is
> discouraged in modern programs, with functions like poll() being
> recommended.

i'm not so sure, but i believe it's in our best interest to have this=20
two-ways: one: we should provide this system ourselves (and since the numbe=
r=20
of fd's can be big, i'd suggest select); two: we should also be prepared to=
=20
let the frontend handle that, and give a callback to it instead.

> > 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 think this is an application's choice, not the library's. As such run
> everything in the single process, allow for an app to fork() for each
> torrent, but do not require that.

a thread/torrent is a bad idea, a torrent server cannot handle the overhead=
 of=20
having 5334 threads...

but we should allow for a single torrent as well...

> Another thing to imagine is that a system might have a global torrent
> handling process, having a unified cache and doing whole bandwidth
> regulation. It would be in the domain of a library to be prepared to
> talk to such a process.

that's unheard of; leave that be, if there is a big system having things li=
ke=20
that, let it be based upon libbt or be silent!

> > 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.
>
> For every X-server you're talking to you'll have a file-descriptor that
> can be watched for being ready for output or having input ready (I have
> looked at this). Programs in general may need an arbitrary number of FDs
> that need monitoring.

X-server are not for us to worry about, frontends handle that, the networki=
ng=20
has all the fd's we need/want.
=2D-=20
Alien is my name and head-biting is my game.