On Mon, Apr 04, 2016 at 07:18:36PM -0700, Philip Guenther wrote: > On Mon, 4 Apr 2016, Martin Natano wrote: > > On Sun, Apr 03, 2016 at 08:20:57PM -0700, Philip Guenther wrote: > ... > > > So, diff below converts several uses of _THREAD_PRIVATE_MUTEX_*() to > > > _MUTEX_*(). Regress tests libc/stdio_threading/* and asr/bin/threads > > > still pass with this. > > > > I think the mutex in gen/getpwent.c and the 'lcl' and 'gmt' mutexes in > > time/localtime.c could be replaced too. See comment inline. > > I looked at those just enough to notice that > a) time/localtime.c has _THREAD_PRIVATE() uses for both localtime and > gmtime, raising the question of whether the 'lcl' and 'gmt' mutexes > should really be 'localtime' and 'gmtime' and sharing backing bits > with those, and > b) gen/getgrent.c uses 'gr' with both _THREAD_PRIVATE() and > _THREAD_PRIVATE_MUTEX_LOCK(); should gen/getpwent.c look a lot more > like that? > > Or not. Digging in on those is on my list, though I wouldn't cry if > someone else did the analysis of whether our getpwent.c is behind the > curve, standard-wise. :-)
Good points. I think the usage of _THREAD_PRIVATE() in getgrent.c is overkill, at least from a standards conformance point of view. Posix specifically mentions that the return values of getgrnam(), getpwnam() et al. may point to a static buffer. If I didn't miss anything the question boils down to whether we want to maintain the added complexity associated with thread private storage in those cases. Portable applications won't be able to benefit from it, as there is no guarantee w/rt thread safety. Ditto for localtime() and gmtime(). natano > > > Philip
