External timeouts can cause bad lock states in multithread environment

[cjbottaro]

trafficstars

Hey Mike, hope all is well.

Consider the snippet:

Timeout.timeout(n) do ... some stuff ... memcache_client.get(some_key) ... more stuff ... end

That can cause a timeout exception to be raised in with_socket_management after @mutex.lock is called, but before execution has entered the begin block, and thus the ensure block won't run and the mutex won't be unlocked.

Solution is simply to put the lock inside the begin block with an additional guard.

-- C

[mperham]

Hey, dude!

Interesting. BTW I'm no longer supporting memcache-client. You'll need to fix it yourself or switch to Dalli.

On Mon, Mar 21, 2011 at 3:28 PM, cjbottaro < [email protected]>wrote:

Hey Mike, hope all is well.

Consider the snippet:

Timeout.timeout(n) do ... some stuff ... memcache_client.get(some_key) ... more stuff ... end

That can cause a timeout exception to be raised in with_socket_management after @mutex.lock is called, but before execution has entered the begin block, and thus the ensure block won't run and the mutex won't be unlocked.

Solution is simply to put the lock inside the begin block with an additional guard.

-- C

Reply to this email directly or view it on GitHub: https://github.com/mperham/memcache-client/pull/16