Re: race condition destroying condition variables

[Samuel Thibault]

Hello,

Brent W. Baccala, on mar. 26 déc. 2017 23:06:13 -0500, wrote:
> Also, the Linux source code in nptl/ includes the following comment:
> 
>   /* If there are waiters which have been already signalled or
>      broadcasted, but still are using the pthread_cond_t structure,
>      pthread_cond_destroy needs to wait for them.  */

Ok, so even if Posix explicitly says that it has undefined behavior,
since nptl behaves fine we should probably behave fine too.

> The problem that I've got now is that I've changed the size of the condition
> variables by adding an extra field,

Not a good idea, for the resaons you mention :)

> First, I'd like to build the packages using the same scripts used to build the
> Debian distribution packages.  Is this available somewhere?

Just run dpkg-buildpackage from the package source, or use pdebuild, or
use a wanna-build infrastructure. Nothing simple, at any rate.

> Next, how will modifying the memory layout of condition variables affect our
> packaging?  I figure that we'll have to bump libc0.3 to libc0.4, and that
> should pretty much do the trick, right?

Yes, but that's a *HUGE* transition, which is painful. Better use symbol
versioning, so that old non-recompiled programs use the old
implementation, and recompiled programs used the new.

> Finally, I'm wondering if we need to change this at all.  The "__data" field 
> in
> struct __pthread_cond seems unused, at least in the libpthreads directory.  Is
> there any use for this pointer?  Or can I use those bits?

AFAICT it was used for compatibility with libcthreads, which we don't
care any more, so I'd say feel free to use it, and avoid the transition
altogether.

Samuel