Issue 393 in memcached: why did we execute function of stop_assoc_maintenance_thread() before the process exit.
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 393 by cfrees...@gmail.com: why did we execute function of stop_assoc_maintenance_thread() before the process exit. https://code.google.com/p/memcached/issues/detail?id=393 In the main function, why did we execute function of stop_assoc_maintenance_thread() before the process exit? -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- --- You received this message because you are subscribed to the Google Groups memcached group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 393 in memcached: why did we execute function of stop_assoc_maintenance_thread() before the process exit.
Updates: Status: Invalid Comment #1 on issue 393 by dorma...@rydia.net: why did we execute function of stop_assoc_maintenance_thread() before the process exit. https://code.google.com/p/memcached/issues/detail?id=393 y u file bugs instead of mailing list :( That's old and relatively incomplete code. If memcached has a graceful way of stopping itself (and more/all of the global variables are removed) it can be embedded/etc. So it tries to be graceful in a few places. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- --- You received this message because you are subscribed to the Google Groups memcached group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Alignment in the binary protocol
I'm looking to implement a client for the binary protocol. I take it there is no padding between memcached requests, and that the keys are values are arbitrary lengths. So, if I send two requests, and the key for the first one is an odd number of bytes, that means the second request will start on an odd byte, and the header will be unaligned? For example, the memcached binary protocol description here uses 'Hello' as the key in the example for GET, https://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol so the entire request is 29 bytes long. This means, if I want to send a second request in the same buffer, I need to start the second header at offset 29 in my buffer, correct? The NFS protocol, for example, specifies that any variable length field is padded with 0-3 zeros, so that the next field can start on a 32 bit boundary. This isn't a problem for me, but could be for some: http://blogs.msdn.com/b/oldnewthing/archive/2015/01/16/10586692.aspx -- --- You received this message because you are subscribed to the Google Groups memcached group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
