Re: [boost] asio review extended till Dec 30th

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-29 16:54:01

Hi Jody,

--- Jody Hagins <jody-boost-011304_at_[hidden]> wrote:
<snip>
> I took a brief look at the epoll implementation.  I don't see
> EPOLLET anywhere, so you are doing Level Triggered.  Curious
> why not Edge Triggered?  I imagine the reason is to prevent
> the implementation from having to either keep track of the FD
> still being ready (until EAGAIN) or keeping its own internal
> buffer to hold the "overflow" but I'm still curious.  It seems
> a framework like this is good for ET since it can take care of
> the added complexities.

When I first added epoll support it was to meet the requirements
of handling tens of thousands of connections. I used the
level-triggered interface because it mapped easily from the
existing select_reactor implementation.

However, I have already been thinking about converting to use
edge-triggered epoll to reduce the number of epoll_ctl calls.
Some recent changes I have made post-review-version are steps in
this direction.

<snip>
> However, of some concern is the fact that you call
> epoll_wait() from multiple threads using the same epoll fd.

Actually epoll_wait is only called from one thread at a time.
This coordination is managed by the task_demuxer_service.

<snip>
> Also, it seems a waste to call epoll_ctl() after each I/O
> operation, regardless of whether it will change the events.

Yep, using edge-triggered epoll should take care of this.

> Before I severely overstep, can you point me to a good example
> of async_read operations?  I see this as a the primary use
> case, yet it does not appear in any of the tutorials.

Yeah, good point! I should add tutorials that demonstrate more
complex interactions.

Maybe have a look at the chat or serialization examples, since
the message format used in these programs is a fixed length
header followed by a body.

> async_read() does not provide the buffer to the handler.  It
> seems the only way to use it is with a function object that
> contains the buffer.  Is that a correct understanding, or do I
> just need to go back to sleep?

Binding it into the function object is one way. But often this
binding is indirect, in the sense that you bind a this pointer
and the buffer is a data member of the class.

Cheers,
Chris