Re: [Libbt-devel] role of libevent

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

Op vrijdag 11 februari 2005 08:26, schreef Elliott Mitchell:
> >From: 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
> > the subtitle of this project, and will be our ticket into being standard
> > distro material.
>
> Being used by lots of program is what makes you into standard material.
> Do you think KDE and GNOME are shipped because they're efficient?

that's frontend stuff, that's different; by comparison, the linux kernel is=
=20
used because it's efficient

> > > > 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 lo=
op
> > > > > 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 ea=
ch
> > > > 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 r=
un
> > > 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 having 5334 threads...
> >
> > but we should allow for a single torrent as well...
>
> Does this mean it is bad to allow an application to make this decision?
>
> Certainly a case like the above an application may not want to have a
> process/thread per torrent, yet it might be perfectly valid for a small
> client to do so.

if they want to, they can just start multiple instances and fork themselves=
,=20
we do not have to think about such things

> > > > I don't know enough X to answer your question, but say libbt provid=
es
> > > > a fd from pipe() back to the application for notification, would th=
at
> > > > 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 pip=
e.
> > >
> > > For every X-server you're talking to you'll have a file-descriptor th=
at
> > > can be watched for being ready for output or having input ready (I ha=
ve
> > > 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
> > networking has all the fd's we need/want.
>
> Applications worry about front-ends. But libraries do need to consider
> how they're going to be used. If libbt has the poll()/select() call
> internally, an application needs to be able to add FDs to the sets.

i don't think frontends need the FDs if libbt is handling the select/poll=20
itself, but if the frontend is taking care of select/poll, it needs the FDs=
et=20
of course...

but i think you are mixing things here, i do not think we are talking about=
=20
the same things here, whether or not an application uses X is their problem=
,=20
it's like like we're going to communicate over the X protocol to the=20
frontend.

we are losing the focus here:

the idea of the library is:
=2D-> provide efficient functions so that all kinds of frontend can use us=
=20
easily.

in that view: we need:
 - a single function that downloads a torrent and finishes (with a callback=
=20
for progress)
 - a group of functions making daemonizing easy
 - a set of functions that manages all torrents and peers (add, del, info)
 - a set of functions to set options to torrents, connections or the librar=
y=20
itself
 - a set of functions to handle the library itself(init, free, stuff like=20
that)

in any case, this mess needs to be clean up first, so i'm adding a header f=
ile=20
that will be installed and describes the functions to the frontends.
=2D-=20
Alien is my name and head-biting is my game.