Dan Kegel wrote:
>
> Dan Kegel wrote:
> > Next step is to rewrite dkftpbench to use Poller. I've been
> > wanting to do that for a long time, but didn't have the
> > energy or an excuse to. I have both now (assuming sufficient coffee :-)
> > and will give it a shot.
>
> First draft is done but not well-tested (and a bit ugly); it's
> http://www.kegel.com/dkftpbench/dkftpbench-0.25.tar.gz
> dkftpbench is now hardwired to use Poller_poll.
>
> So that leaves
> * generalizing dkftpbench so you can compile it to
> use any of the Poller implementations, not just Poller_poll
> (and do it without virtual function call overhead)
>
> * modifying dkftpbench to support multiple local addresses

Uploaded second draft of Poller rewrite. It's no longer as ugly.
In fact, integrating Poller cleaned things up a bit.
The code is no longer O(N) anywhere in number of sockets, I think.
http://www.kegel.com/dkftpbench/dkftpbench-0.26.tar.gz

The error handling's a bit dodgy. I need to write a real integration
test -- with a toy ftp server that can generate various error
conditions on demand -- to verify that ftpbench handles error
conditions correctly. But probably I'll just keep muddling along
without one.

I think I'll make it so you tell configure which of the Pollers
you want to use, and have a "Poller_all.h" and a fake "Poller_all"
data type that are controlled by configure. None of this runtime
polymorphism for me, don't want to risk wasting half a microsecond
on a virtual function call :-)
- Dan