Updates:
Status: Invalid
Comment #9 on issue 62 by dsallings: Patch: connection queue simplification
http://code.google.com/p/memcached/issues/detail?id=62
I don't think there's a bug here. This looks like something interesting
could come
out of it, but there are a lot of things to c
Comment #7 on issue 62 by dmitry.isaikin: Patch: connection queue
simplification
http://code.google.com/p/memcached/issues/detail?id=62
Sorry, I misunderstood).
Yes, partial reading may be a problem. I insert abort() for this case.
Struct is writing atomicaly to the pipe. So libevent would
Comment #6 on issue 62 by overflow5: Patch: connection queue simplification
http://code.google.com/p/memcached/issues/detail?id=62
I agree with removing the connection queue and the locking.
I was a little concerned about sending 20 bytes through a pipe that can
lead to odd
things like readi
Comment #5 on issue 62 by dmitry.isaikin: Patch: connection queue
simplification
http://code.google.com/p/memcached/issues/detail?id=62
Unnecessary copying of 20 bytes of data on the stack is more fast than
dynamic memory
allocation + mutex locking. Size of sending struct may be decrease t
Comment #4 on issue 62 by overflow5: Patch: connection queue simplification
http://code.google.com/p/memcached/issues/detail?id=62
I'd rather send a pointer to the CQ_ITEM over the pipe instead of the whole
struct.
That would increase the number of connections that can be on the pipe and
Comment #3 on issue 62 by dmitry.isaikin: Patch: connection queue
simplification
http://code.google.com/p/memcached/issues/detail?id=62
Yes, in case of many simultaneous connections.
Client connections is accepted by the listening thread. Pipe is used only
for resend
client information to
Comment #2 on issue 62 by dorma...@rydia.net: Patch: connection queue
simplification
http://code.google.com/p/memcached/issues/detail?id=62
Your change will cause clients to occasionally block on the pipes, I'm
pretty sure?
--
You received this message because you are listed in the owner
