Do we need sys_open() et al (_LARGEFILE64_SOURCE and open64())?
abartlet at samba.org
Sat Mar 24 20:55:04 MDT 2012
On Sat, 2012-03-24 at 07:11 -0700, Jeremy Allison wrote:
> On Sat, Mar 24, 2012 at 02:58:19PM +0100, Volker Lendecke wrote:
> > On Sat, Mar 24, 2012 at 02:43:15PM +0100, Jelmer Vernooij wrote:
> > > At the moment we have two trivial wrappers for fork() and getpid() in
> > > lib/util/system.c. These wrappers exist so that we can cache the PID and
> > > avoid a system call when getpid() is called.
> > >
> > > Is this optimization actually still worth the trouble these days? We
> > > don't seem to have any regularly called code paths that need it. The
> > > printing code seems to use it as a simple way of identifying a single
> > > server in the database, but that can be worked around by just using a
> > > single variable there.
> > >
> > > Furthermore, there is the risk that we end up not updating the pid after
> > > a fork() - thus ending up with sys_getpid() returning the wrong pid. For
> > > example, our libraries are used in various applications, either directly
> > > or as part of e.g. openchange, which don't use sys_fork() but plain fork.
> > >
> > > Thoughts?
> > I think that can go. I think at least glibc caches that
> > anyway, and we try to move away from getpid to
> > messaging_server_id() and friends.
> +1 from me also (and I added them originally :-).
> No longer needed - thanks !
While we are thinking about sys_ wrappers, I wondered if we still really
needed the sys_*() wrappers for open64 etc?
man feature_test_macros(7) says:
Expose definitions for the alternative API specified by the LFS
(Large File Summit) as a "transitional extension" to the Single UNIX
Specification. (See http://opengroup.org/platform/lfs.html.) The
alternative API consists of a set of new objects (i.e., functions and
types) whose names are suffixed with "64" (e.g., off64_t versus off_t,
lseek64() versus lseek(), etc.). New programs should not employ this
interface; instead _FILE_OFFSET_BITS=64 should be employed.
Defining this macro with the value 64 automatically converts
references to 32-bit functions and data types related to file I/O and
file system operations into references to their 64-bit counterparts.
As such, are there any systems that we need that have
_LARGEFILE64_SOURCE but not _FILE_OFFSET_BITS?
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical