Subject: Re: [linux-audio-dev] userspace atomic primitives for multithread and SMP applications?
From: Jack O'Quin (joq_AT_io.com)
Date: Fri Aug 22 2003 - 19:10:52 EEST
Ingo Oeser <ingo.oeser_AT_informatik.tu-chemnitz.de> writes:
> > To compile my application for all supported platforms, I would need to
> > collect all these header files and wrap them with appropriate
> > #ifdef's, right? Or else, I could put them in subdirectories and
> > select the right one at ./configure time.
>
> Yes, there is no other way to include that kind of code.
> This kind of code should actually be in the compiler, but they
> don't seem to care.
Surely not the compiler, itself. Perhaps in a compiler-related
library. Or, maybe glibc could export this stuff.
Actually, my Debian system has two copies in different C++ header
directories, probably because I have several compiler packages
installed...
libstdc++5-dev: /usr/include/c++/3.2/i386-linux/bits/atomicity.h
libstdc++3-dev: /usr/include/g++-v3/i386-linux/bits/atomicity.h
I would actually prefer a separate LGPL-ed package supporting as many
architectures as reasonably possible. That would make application
code easier to port to non-GCC, non-glibc, or non-Linux platforms.
The main reason I don't want to include all these files in my own
sources is that I have no reasonable way to test or maintain all those
snippets of assembler language for exotic machines to which I have no
access.
I'd love to see a small team with access to a suite of test machines
step up to supporting these functions on as many machines as possible.
I wouldn't mind doing a lot of that work, myself. But I couldn't do
an adequate job without access to additional resources and help from
people familiar with various processor architectures.
A carefully chosen set of these header files with a library of test
cases and good documentation would be a valuable resource for the open
software community in general, and LAD in particular. In fact, I'm
surprised no one has done this already. I guess people with the
needed expertise and access to those sorts of machine resources have
bigger fish to fry.
Regards,
-- Jack O'Quin Austin, Texas, USA
This archive was generated by hypermail 2b28 : Fri Aug 22 2003 - 19:16:17 EEST