Hi Maxim, Thanks for the pointer to libevent; it is interesting. Please find my reply below. --- Maxim Yegorushkin <e-maxim@yandex.ru> wrote:
Iain Hanson wrote:
On Fri, 2005-04-01 at 19:57 +0400, Maxim Yegorushkin wrote:
By the way, we use libevent and are happy with it. It's portable (Linux/Windows) and has very simple interface. I just don't see a need for the stuff you guys are discussing here.
Because we like our libraries spelt in C++ :-).
So do I.
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(). 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 ;)
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). Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs
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
Don G wrote: []
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).
IMO, this contradicts with the thread title. Non-blocking and async are not the same. Non-blocking event model with select/poll/epoll is when you get notified when a read or write won't block. Async model with Windoze Overlapped I/O is when you get notified when a read or write has been completed. The latter is, IMO, higher level stuff and can be implemented over the former (and this is how I've been doing it in my projects). I thought you guys were talking about the async model here. -- Maxim Yegorushkin
participants (2)
-
Don G -
Maxim Yegorushkin