On Sun, Nov 04, 2007 at 12:15:56PM -0800, Steven Grimm wrote:
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
On Sun, Nov 04, 2007, Steven Grimm wrote:
Would this be for listen sockets, or for general read/write IO on an
FD?
Specifically for a mixed TCP- and UDP-based protocol where any thread
is equally able to handle an incoming request on the UDP socket, but
TCP sockets are bound to
On Sun, Nov 04, 2007 at 03:18:42PM -0800, Steven Grimm wrote:
You've just pretty accurately described my initial implementation of
thread support in memcached. It worked, but it was both more CPU-
intensive and had higher response latency (yes, I actually measured
it) than the model I'm
Christopher Layne wrote:
On Sun, Nov 04, 2007 at 04:23:01PM -0800, Scott Lamb wrote:
It wasn't what I expected; I was fully confident at first that the
thread-pool, work-queue model would be the way to go, since it's one
I've implemented in many applications in the past. But the numbers said
