Thus far I don't have any documentation however I intend to add some
doxygen-based documentation in the future. I'll be particularly
motivated to write documentation if someone expresses interest in
reading it ;).
This seems interesting; I'd certainly like to read some documentation.
-Steve
It avoids using select() unless there's absolutely no other choice, in
part because of the artificial limits of select() but mostly because
select() is inefficient for large numbers of monitored file descriptors.
Most of the point of libevent is that it's a generic wrapper around
OS-specific e
As the guy who added thread support to memcached, I feel qualified to
answer this one:
What libevent doesn't support is sharing a libevent instance across
threads. It works just fine to use libevent in a multithreaded process
where only one thread is making libevent calls.
What also works, a
Dave Gotwisner wrote:
I personally hate the proliferation of typedefs. I have seen u8, U8,
u_int8, uint8, and many others that all express the same thing.
(similarly for 16, 32, and 64 bit sizes).
The lack of a common standard is the problem, IMO, not the existence of
typedefs per se. The un
Dave Gotwisner wrote:
Using your example, if you had a 8, 16, 64, and 128 bit native types,
and you wanted an EXACTLY 32 bit type, how would it work? Given ANSI
only specifies char, short, long, and long long, when we support 256
bit native types, and you still need the smaller ones (or everyt
If you're calling event_init() more than once, you never want to call
event_set() and other such functions. You want to call event_set_base()
and pass in the handle you get back from event_init(). Using the
current_base versions of the event calls in a multithreaded app (where
you are using lib
On Nov 4, 2007, at 8:13 AM, Marc Lehmann wrote:
This would create additional loops (event_bases). The difference is
that
these cannot handle signals (or child watchers) at all, with the
default loop
being the only one to do signal handling.
This seems like a totally sane approach to me. Hav
On Nov 4, 2007, at 3:03 PM, Adrian Chadd wrote:
On Sun, Nov 04, 2007, Steven Grimm wrote:
Now if only there were a way to wake just one thread up when input
arrives on a descriptor being monitored by multiple threads... But
that isn't supported by any of the underlying poll mechanisms a
On Nov 4, 2007, at 3:07 PM, Christopher Layne wrote:
The issue in itself is having multiple threads monitor the *same* fd
via any
kind of wait mechanism. It's short circuiting application layers, so
that a
thread (*any* thread in that pool) can immediately process new data.
I think
it would
