5:48 p.m.
Hi list
In this bug https://bugzilla.redhat.com/show_bug.cgi?id=743249 the
user requests to enable thread safety in the cfitsio library. I'm not
completely sure of substituting one library by the other.
So I was wondering if it's a good idea to compile the code twice and
distribute two versions of the library, libcfitsio.so and
libcfitsio-mt.so. This implies to distribute two pkg-config files,
cfistio.pc and cfitsio-mt.pc
Are there any recommendations or good practices regarding this issue?
Best, Sergio
6:12 p.m.
...Debian's "alternatives" system...?
On Oct 28, 2011 6:49 PM, "Sergio Pascual" <sergio.pasra(a)gmail.com> wrote:
Hi list
In this bug https://bugzilla.redhat.com/show_bug.cgi?id=743249 the
user requests to enable thread safety in the cfitsio library. I'm not
completely sure of substituting one library by the other.
So I was wondering if it's a good idea to compile the code twice and
distribute two versions of the library, libcfitsio.so and
libcfitsio-mt.so. This implies to distribute two pkg-config files,
cfistio.pc and cfitsio-mt.pc
Are there any recommendations or good practices regarding this issue?
Best, Sergio
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
6:45 p.m.
On Fri, Oct 28, 2011 at 07:12:31PM -0400, Bruce-Robert Pocock wrote:
...Debian's "alternatives" system...?
Alternatives would be the wrong answer. Alternatives is really for
sysadmins to select between one or another equivalent things for use system
wide.
Here we have something that's more likely a developer choice. The developer
may be a Fedora end user or they may be the upstream for one of our
packages.
-Toshio
6:34 p.m.
On Sat, 29 Oct 2011 00:48:53 +0200
Sergio Pascual wrote:
So I was wondering if it's a good idea to compile the code twice
and
distribute two versions of the library, libcfitsio.so and
libcfitsio-mt.so. This implies to distribute two pkg-config files,
cfistio.pc and cfitsio-mt.pc
Are there any recommendations or good practices regarding this issue?
boost does that too, so having both libraries should be a good
practice.
Completely replacing the library with a thread safe version
would make the library slower, when using without threads. Don't know
if that's a big issue here?
Tom
9:49 p.m.
Thomas Spura <tomspur(a)fedoraproject.org> writes:
Sergio Pascual wrote:
> So I was wondering if it's a good idea to compile the code twice and
> distribute two versions of the library, libcfitsio.so and
> libcfitsio-mt.so. This implies to distribute two pkg-config files,
> cfistio.pc and cfitsio-mt.pc
Completely replacing the library with a thread safe version
would make the library slower, when using without threads. Don't know
if that's a big issue here?
FWIW, I think that's mostly a twentieth-century problem. With modern
toolchains and libraries there isn't likely to be much difference.
I would suggest taking a negative approach: do not ship the
non-thread-safe version unless you have positive evidence that it's
meaningfully faster, or there's a known incompatibility in the
thread-safe version. It only takes one episode of debugging an
oh-you-should-have-used-the-thread-safe-version problem to wipe out any
possible benefit from using a not-thread-safe-version, when you account
for person-hours saved or wasted by each.
To give a concrete example: there is no non-thread-safe version of glibc
in Fedora.
regards, tom lane
4:31 a.m.
On Fri, 28 Oct 2011 22:49:52 -0400
Tom Lane wrote:
Thomas Spura <tomspur(a)fedoraproject.org> writes:
> Sergio Pascual wrote:
>> So I was wondering if it's a good idea to compile the code twice
>> and distribute two versions of the library, libcfitsio.so and
>> libcfitsio-mt.so. This implies to distribute two pkg-config files,
>> cfistio.pc and cfitsio-mt.pc
> Completely replacing the library with a thread safe version
> would make the library slower, when using without threads. Don't
> know if that's a big issue here?
FWIW, I think that's mostly a twentieth-century problem. With modern
toolchains and libraries there isn't likely to be much difference.
It depends on the use case. When this library is called very often in
an HPC environment, it matters, if your program is running 10% slower
or not (I once had such a problem, when writing my own pseudo random
number generator.).
I would suggest taking a negative approach: do not ship the
non-thread-safe version unless you have positive evidence that it's
meaningfully faster, or there's a known incompatibility in the
thread-safe version. It only takes one episode of debugging an
oh-you-should-have-used-the-thread-safe-version problem to wipe out
any possible benefit from using a not-thread-safe-version, when you
account for person-hours saved or wasted by each.
To give a concrete example: there is no non-thread-safe version of
glibc in Fedora.
I agree. IO is slow anyways, so it's unlikely that users are hit badly
by a slightly slower library. (But still don't know the use case of it,
so it's up to the maintainer which way to go.)
Tom
10:30 a.m.
Thanks for the suggestions.
So what I'm going to do is:
* Enable multithread support. Check with packagers of dependent
software if they find any problem.
* If there is any problem provide the two libraries
* if not, provide just the multithreaded version
Regards, Sergio
2011/10/29 Thomas Spura <tomspur(a)fedoraproject.org>:
On Fri, 28 Oct 2011 22:49:52 -0400
Tom Lane wrote:
> Thomas Spura <tomspur(a)fedoraproject.org> writes:
> > Sergio Pascual wrote:
> >> So I was wondering if it's a good idea to compile the code twice
> >> and distribute two versions of the library, libcfitsio.so and
> >> libcfitsio-mt.so. This implies to distribute two pkg-config files,
> >> cfistio.pc and cfitsio-mt.pc
>
> > Completely replacing the library with a thread safe version
> > would make the library slower, when using without threads. Don't
> > know if that's a big issue here?
>
> FWIW, I think that's mostly a twentieth-century problem. With modern
> toolchains and libraries there isn't likely to be much difference.
It depends on the use case. When this library is called very often in
an HPC environment, it matters, if your program is running 10% slower
or not (I once had such a problem, when writing my own pseudo random
number generator.).
> I would suggest taking a negative approach: do not ship the
> non-thread-safe version unless you have positive evidence that it's
> meaningfully faster, or there's a known incompatibility in the
> thread-safe version. It only takes one episode of debugging an
> oh-you-should-have-used-the-thread-safe-version problem to wipe out
> any possible benefit from using a not-thread-safe-version, when you
> account for person-hours saved or wasted by each.
>
> To give a concrete example: there is no non-thread-safe version of
> glibc in Fedora.
I agree. IO is slow anyways, so it's unlikely that users are hit badly
by a slightly slower library. (But still don't know the use case of it,
so it's up to the maintainer which way to go.)
Tom
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
--
Sergio Pascual http://guaix.fis.ucm.es/~spr
gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC
Departamento de Astrofísica -- Universidad Complutense de Madrid (Spain)
4556
days inactive
4557
days old
packaging@lists.fedoraproject.org
6 comments
6 participants
participants (6)
-
Bruce-Robert Fenn Pocock -
Sergio Pascual -
Sergio Pascual -
Thomas Spura -
Tom Lane -
Toshio Kuratomi