libpurple in server

[Allan Clark]

On 6/1/07, Ethan Blanton <elb at pidgin.im> wrote:
> Christopher Baus spake unto us the following wisdom:
> > > So, while this is true at some level, you should be able to handle an
> > > awful lot of IM connections before this becomes a problem.  Most of
> > > your I/O will be simple buffer reads and writes, and the only real
> > > cost you'll pay is the system call overhead.  (Disk I/O in libpurple
> > > is about the only thing which might degenerate into something other
> > > than a buffer read or write, as it is blocking.)
> >
> > Sorry, when I said I/O, I meant disk I/O.  For where I'm at right now,
> > disk I/O  performance is fine, but I expect this to be the first
> > bottleneck I run into.
>
> Fortunately, this is pretty easy to fix, and completely unrelated to
> the threaded-ness of libpurple.  We do disk accesses in a *very* small
> number of well-contained places.

...and in the case that this does become a problem, that could be
passed to an I/O thread of some kind, like a write-behind cache.

Allan (writing as if he knew anything about caching.. ha!)
-- 
allanc at chickenandporn.com  "金鱼" http://dr.chickenandporn.com/