Code review comment for lp://staging/~chipaca/snappy/lock-ness

Revision history for this message
John Lenton (chipaca) wrote :

Remember the intention is to move away from having multiple things building against "the snappy api"; clients would use the rest api. There's a question about what that means for u-d-f, but locking shouldn't be an issue for it anyway.

The only downside to moving locking down in the call stack is that it's not clear where to lock, exactly, unless a lot of things grow a boolean "lock is already held" flag.

I can of course move the mmutex package one level down, but I don't think that's what you meant :)

« Back to merge proposal