libpurple in server

[Christopher Baus]

> Christopher Baus spake unto us the following wisdom:
>> I'm currently working on such a project.  I think the only potential
>> issue
>> is handling the single threaded event loop in a scalable manner.  For
>> instance doing I/O when handling messages is going to block the entire
>> glib event distribution until the I/O completes.  This will result in
>> poor
>> CPU and I/O utilization.
>
> 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.