Comment #1 on issue 331 by [email protected]: assoc_maintenance_thread
unlocks mutex without locking first
http://code.google.com/p/memcached/issues/detail?id=331
Did this cause a bug or is this from an audit?
That little bit of code in the assoc thing was really awkward and feels
wrong to me, but that's where it ended.
The unlock is a bit of a bootstrapping issue that might go away if it's
restructured a little to use a "once on startup" flag. It unlocks right
before the thread sits on a condition, because when it wakes up from the
condition the first thing it does is lock the slab mover.
So if you add a pause before that resume it'll just deadlock when the
expander actually runs the first time.
If it's causing some bug we'll see about fixing it sooner than later,
though?
--
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
