MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 22 Jun 2022 18:44:45 +0200
Message-Id: <CKWTBZV0CKNR.2S5ZYWZVZ5KDP@sumire>
From: "alice" <alice@ayaya.dev>
To: "Tomas Kolda" <koldat@gmail.com>, "Ariadne Conill"
 <ariadne@dereferenced.org>
Cc: <~alpine/devel@lists.alpinelinux.org>
Subject: Re: Native Alpine GLibc support (NEW)
References: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com> <a3367d7-d3c5-4755-289e-37507033405f@dereferenced.org> <CAGFcrMmSG6RbG_O+NrHZ0Cys=6stLy59JjBsqd=BnfncLXdiCQ@mail.gmail.com>
In-Reply-To: <CAGFcrMmSG6RbG_O+NrHZ0Cys=6stLy59JjBsqd=BnfncLXdiCQ@mail.gmail.com>

On Wed Jun 22, 2022 at 2:04 PM CEST, Tomas Kolda wrote:
> > Yes, I have written about this before[0].  Mixing glibc and musl
> > environments will lead to instability -- this can be overcome with prop=
er
> > multi-arch support, but we have not implemented this in Alpine yet (and
> > apk-tools would need some minor changes to the solver to become
> > multi-arch aware).
> >
> I know. That is why I want to have glibc build. Many JNI dependencies
> in Java is glibc based for example. It is really hard to keep up.
> >
> > Locks in musl are done with atomics.  The advantage is probably due to =
the
> > fact that glibc has lock elision, which musl does not yet have.
> > Investigating the addition of lock elision to musl is on my list of thi=
ngs
> > to do eventually.
> >
> > Which JVM are you using?  OpenJDK 17 and later have their own internal
> > implementation of lock elision for Java/JNI locks, which should improve
> > performance.
> >
> I tried JDK 8, 11, 17. Latest versions. No difference. Yes it is in
> futex as you said. From user perspective it matters, because it is 5
> times slower. As I said I do not believe MUSL can dramatically change
> pthread implementation as it is most sensitive part and very hard to
> test. It is very long run.
>
> > - customize hundreds of APKBUILDs which will require the cooperation of
> > package maintainers (who may be skeptical)
> I do not agree with this. Most changes in that 300 set was in the
> basic packages that was requiring MUSL tweaks. There will be less
> tweaks after we will go further as more complex applications are using
> libraries that are solved already. Anyway even from statistical
> perspective it is 17 changes for 300 packages -> 5-6%. I am not sure
> how many packages are in Alpine, but we can extrapolate.
>
> I also do not agree that someone would just for one "if" be pushing
> change out. There are many patches for all other reasons. I am
> positive that people tend to help others. And this change does not
> generate any work for them if they will not need to support it. They
> will just try to keep it in working way.
> >
> > Speaking in personal capacity, I do not think the Alpine TSC will appro=
ve
> > this proposal because the project is already overwhelmed with work to d=
o.
> >
> Agree. I think that for start it would be great to at least allow "if"
> patches to be able to merge it. It will be noop for Alpine.
the example patches you have posted on github are very far from no-ops
at all, they require constant vigilance on how to maintain the
musl-specific patches to be separate and still work. i don't think
anyone wants to add musl specific patches as musl && msg && patch -p1,
and they were all also removed from checksums.

if they were part of aports, then it becomes the responsibility of the
people that work on aports to ensure that everything still works. but
since aports itself does not feed an actual glibc apk system.. that
doesn't really make sense. they only make sense as an entire separate
project where you either keep specific patches to apply to get aports to
build, or as a fork of aports (named something else) where you rebase
your changes on top every once in a while.

is it a lot of work? sure. it's not any more work than making them in
the first place, though, and it gives zero additional work to anyone
that maintains aports that they didn't ask for.

>
> See example changes here:
> https://github.com/koldat/alpine/pull/1

apologies- i accidentally sent an empty reply before.