External timeouts can cause bad lock states in multithread environment

[cjbottaro]

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 <
reply@reply.github.com>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:
#16