Hi Anthony! On Fri, Mar 14, 2008 at 4:00 PM, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
Hi Dean,
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
http://memcachepp.svn.sourceforge.net/viewvc/memcachepp/trunk/test/memcache_...
is the test which throws on destroying memcache handles, and related to locking mutexes.
Thanks. I'll try it on my linux box later.
This will not come as a surprise, but I think I've found the cause -- and the solution.
This also uses ASIO underneath, and I'm not sure if it may be ASIO related. For one thing, it throws a boost::system::system_error which encapsulates the 'mutex: Invalid argument' in the 'what()' method. I checked Boost.Thread and it throws system errors like ASIO does -- so right now I'm limiting it to just Boost.Thread because it seems to be the more logical place from which mutex errors would come from.
Boost.Thread doesn't throw system_error anywhere. Most throws are thread_resource_error, and some are lock_error, but none are system_error.
It does seem like ASIO is involved somehow. The problem lies in the destruction of ASIO sockets expecially once the io_service it's tied to is already deleted. This may better be called as a 'dangling reference' problem, which is caused by my relying on the destructor of the containers in the memcache handle to do the right thing in the right order. All I had to do is add appropriate clearing of the containers in the handle at the destructor to make sure that the elements of the containers are deleted before the io_service is stopped (and later deleted). This evidently fixed the problem in the platform I'm using, and a subtle bug that doesn't appear in other platforms (yet). Charge this as PEBKAC instead of an actual bug. ;-) Have a good day everyone, and sorry for the noise. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://blog.cplusplus-soup.com] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523]