Nick, Patrick, et all,
Yes, thank you! This is exactly what I wanted to know. Trond Norby has
given me a Launchpad repo of libmemcached that uses select to implement
poll that I'll be testing on Windows.
I've been quite pleased at how good at how well libevent compiles on
Windows using mingw. What we're trying to do is get both a working
memcached server and libmemcached client working on Windows.
The one thing I still need to find out is if anyone has looked into the
issue where libevent has a problem compiling on win64. The first error
I had was:
log.c:104:1 error: conflicting types for 'event_sock_err', so I changed
the 'sock' arg in log.c to an int, just like log-internal.h. That
helped the compile get to link, which it then failed on:
libtool: link: undefined symbols not allowed in i686-pc-mingw32 shared
libraries
false cru ./lib/libevent.a event.o buffer.o buffervent.o ...
Maybe there's an issue with mingw on this box, not sure. Is anyone on
this list successfully getting a build in win64?
Thank you for your replies - they were very informative!
--Patrick
Patrick C wrote:
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 <nickm@xxxxxxxxxxxxx>
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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.
|