Re: [Libbt-devel] role of libevent

[Elliott M. <eh...@m5...>]

>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?

> > > 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 
> 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.

> > > 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 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.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EH...@gr... PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/