Thanks, applied to master.
On 5 June 2014 06:26, Ethan Jackson wrote:
> Acked
>
>
> On Tuesday, June 3, 2014, Joe Stringer wrote:
>
>> This patch refactors the code around ukey creation and lookup to
>> simplify the code for callers. A new function ukey_acquire() combines
>> these functions an
Acked
On Tuesday, June 3, 2014, Joe Stringer wrote:
> This patch refactors the code around ukey creation and lookup to
> simplify the code for callers. A new function ukey_acquire() combines
> these functions and attempts to acquire a lock on the ukey. Failure to
> acquire a lock on the ukey is
I agree, that would look a bit tidier. I'll send a patch.
On 3 June 2014 08:53, Ethan Jackson wrote:
> I'm wondering if it'd be cleaner to have ukey_create() return a locked
> ukey, and to pull the try_lock() into the critical section for the
> ukeys map? I.E.
>
> lock_hmap()
> ukey = ukey_loo
I'm wondering if it'd be cleaner to have ukey_create() return a locked
ukey, and to pull the try_lock() into the critical section for the
ukeys map? I.E.
lock_hmap()
ukey = ukey_lookup()
if (!ukey) {
//create and insert
} else {
// trylock
}
unlock_hmap()
What do you think?
On Thu, Ma
This patch refactors the code around ukey creation and lookup to
simplify the code for callers. A new function ukey_acquire() combines
these functions and attempts to acquire a lock on the ukey. Failure to
acquire a lock on the ukey is usually a sign that another thread is
handling the same flow co