As Nick said, the libevent source itself is a great example of abstracting poll() functionality on multiple platforms, using the locally optimized methods of epoll, kqueue, etc depending on the operating system. This is primarily designed for high-performance network daemons (and sometimes clients) which have a great number of file descriptors to watch.
The client would only have a couple of file descriptors to watch at the most (up to the # of servers added for hashing), so substituting poll() for select() should be easy and safe, with little to no performance trade-off. Plus, the client get/set requests are blocking anyway, which makes it pretty simple to implement. -Patrick 2009/12/1 Nick Mathewson <[email protected]> > On Wed, Nov 25, 2009 at 02:44:37PM -0500, Patrick Galbraith wrote: > > Hi there all! > > > > I'm working on trying to port libmemcached to Windows. It is not an easy > > task! I've just found that libmemcached uses poll() and this is a bit of > > a road-block! What do you guys do to get cross-platform support? How do > > you transparently use poll() or other mechanisms to provide the > > functionality that is required depending on platform? > > I'm not sure what exactly you're asking; I'll answer two possible > variants of your question. If you meant something else, my apologies. > > If you mean, "how do Libevent users transparently use poll() or other > mechanisms?" then the answer is "by using Libevent": Libevent knows > about lots of different platform-specific poll()-like things, and > tries to use whichever is fastest among the available options. You > can probably find examples of how to use Libevent by looking in the > regular memcached source. > > > If you mean, "how do Libevent users transparently use poll() or other > mechanisms?" then the answer is, "by having a separate implementation > for each backend mechanism, compiling as many as will compile on a > given platform, and selecting whichever one of the compiled ones works > best at runtime." The responsibility of each backend is basically: > - Know how to start caring about an fd for reading/writing > - Know how to stop caring about an fd for reading/writing > - Know how to wait up to a given number of seconds for fds to be > ready to read/write, and > For an example of one of the simpler such backends, see select.c in > the Libevent source. See kqueue.c or epoll.c for an example of what > we do for a fancier backend. > > hope this helps, > -- > Nick > *********************************************************************** > To unsubscribe, send an e-mail to [email protected] with > unsubscribe libevent-users in the body. >
