libpurple in server
allanc at chickenandporn.com
Fri Jun 1 23:41:15 EDT 2007
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/
More information about the Devel