[boost] Re: Asynchronicity (long)

From: Maxim Yegorushkin (e-maxim_at_[hidden])
Date: 2005-04-02 03:57:16

Don G wrote:

[]

>> Nevertheless, I like to keep simple things simple. I don't
>> feel like I need a glue layer over simple socket and epoll
>> api's.
>
> epoll() is not available on even all Unix systems, let alone with
> Windows sockets. AFAIK, the only multi-wait method on Windows is
> select().

I know that.

But I also know that modern monster sites like http://www.livejournal.com/  
would not be possible without epoll. (Well, I may be exaggerating a  
little). To handle that huge number of hits without doing MySQL lookup for  
each livejournal uses memcahched, which they say does 90% hits and only  
10% misses. memcahched in turn is build solely around libevent. epoll  
provides the lowest latency descriptor readiness notification means (in  
user space). Very simple and powerful architecture.

Having said that, nowadays epoll support is a requirement for any linux  
which is going to be used in any decent networking.

> That said, I don't find select/poll/epoll et.al. very pleasant and
> would like to see them hidden completely. Manual mantenance of
> structures and bit flags is not my idea of fun, and for the novice to
> intermediate level developer this can be a frustrating and error
> prone experience. Obviously, this is a bit of a subjective matter,
> but the C nature of these API's makes them less than ideal for a C++
> bigot such as myself ;)

select bit manipulation is ugly and boring. poll is much better. epoll is  
pretty much as simple as one can get.

>> What I might need is an event demultiplexor. Heavy loaded
>> servers I'm working on are event driven. Each event which
>> is not naturally a file descriptor readiness change is
>> transformed in a socket(pair) write, so that it can be
>> demultiplexed by epoll_wait(). Thus, an application just
>> handles events in a loop around epoll_wait(). So, I might
>> need a little syntactic sugar around this stuff, but I have
>> not elaborated my generic implementation yet.
>
> This is exactly the kind of thing a general async library would solve
> for you. When something is done, instead of calling send/write on a
> socket that exists solely to make epoll happy, just queue the C++
> call (i.e., a boost::function<> object).

This is what I'm talking about - my problems were solved long time ago.  
I'm happy with a C-style callback taking void* in libevent. And it's  
trivial to wrap it to make it accept and callback arbitrary function  
objects. I've been already living in a perfect world...

-- 
Maxim Yegorushkin