Date: Mon, 11 Feb 2019 08:05:33 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org Subject: Re: switch to non-zero PTHREAD_*_INITIALIZER Message-ID: <Pine.GSO.4.64.1902110754080.20469@sea.ntplx.net> In-Reply-To: <92707.1549878222@critter.freebsd.dk> References: <92707.1549878222@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Feb 2019, Poul-Henning Kamp wrote: > Right now most of our PTHREAD_*_INITIALIZER macros are defined as NULL. > > This is a bad choice from a code quality point of view, because it means > that > > pthread_t my_mutex; > > and > > pthread_t my_mutes = PTHREAD_MUTEX_INITIALIZER; > > act the same, which they are not. > > I suggest that we should change the macros to a non-NULL value, and > add a check for NULL values which emit a warning about the lack of > initialization. > > Comments ? You'll get warnings from anything that hasn't be rebuilt with the new initializers, including other languages that have overlays to the same C structures (well, really ours are pointers to structs). I'm not really against this, but I'd rather see our mutex, condvar, etc, be real structs instead of pointers to structs. This would hopefully get rid of the whole malloc mess inside libthr and simplify pthread_XXX_setpshared(). I'd think that we've evolved the pthread API enough to pick some large enough storage size for our structs such that we won't have to change it again. Of course, even with versioned libraries, this change would probably require a library version bump. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1902110754080.20469>