PTHREAD_MUTEX_ROBUST for tdb?

[Rusty Russell]

On Wed, 18 May 2011 09:52:35 +0200, Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote:
> On Wed, May 18, 2011 at 10:17:15AM +0930, Rusty Russell wrote:
> > As I just replied on a private variant of this:
> > 
> > Yes.  It's not very portable, but it is in recent Linux and glibcs.
> > 
> > As far as I can tell, embedding a pthread mutex into a memory mapped
> > file is going to be a bit of a nightmare :(  Its size is not necessarily
> > stable over glibc changes, for example.
> 
> So a strict requirement is to run with completely different
> glibc implementations on a single host against the same tdb
> file? True, this will kill it. Probably shared robust
> mutexes are just a broken concept then. Sorry for the noise.

I don't think we need that much, but obviously persistence over reboots
is important.  We might be able to store the size somewhere and say
"oops, if you don't fit, fall back to fcntl locks".

I take advantage of the range-like properties of fcntl locks at the
moment, but we could use some different scheme.

> > We could use the robust futex support and open-code it for Linux
> > ourselves, at least for x86 which we care about.  This would be a fun
> > project, but a non-trivial one.
> 
> How does this fit with a distant future goal of making tdb
> threadsafe? The way I understood the set_robust_list call is
> that there is one robust list per thread, and glibc when
> doing threads would overwrite the list maintained by tdb. Am
> I wrong here?

Yes, it wouldn't be available for threads.  Which is a nasty limitation,
so I think embedding mutexes would be best.

I will ensure that we've at least experimented with it before we
finalize the TDB2 ABI, so we can add it later if it works out...

Thanks,
Rusty.