Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Mar 2012 22:30:40 +0100
From:      Jilles Tjoelker <jilles@stack.nl>
To:        Ed Schouten <ed@FreeBSD.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r233345 - head/lib/libc/gen
Message-ID:  <20120323213040.GA70656@stack.nl>
In-Reply-To: <201203230826.q2N8QW0m064618@svn.freebsd.org>
References:  <201203230826.q2N8QW0m064618@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 23, 2012 at 08:26:32AM +0000, Ed Schouten wrote:
> Author: ed
> Date: Fri Mar 23 08:26:31 2012
> New Revision: 233345
> URL: http://svn.freebsd.org/changeset/base/233345

> Log:
>   Make utmpx(3) thread safe if we support TLS.

>   Because the utmpx interface is generally not required to be thread-safe,
>   but it is nice to have, if easy to do so. Therefore don't make a mess
>   out of the code and only use it if __NO_TLS is not defined.

Hmm, I think this is a portability trap, at least as long it is
supported to have a platform with threading but without __NO_TLS.

Besides, I am not sure if this functionality is worth 12 or 20 bytes of
memory per thread because most applications do not use it. I think a
pthread_key_create() when the first thread calls an utmpx function
optimizes for the case where utmpx is not used or used by only one
thread.

A reason to make utmpx thread-safe could be that glibc does it or
popular applications (almost) need it.

-- 
Jilles Tjoelker



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120323213040.GA70656>