4 ms·

> The musl author doesn't believe programs should unload code. Therefore, you're not allowed to do it. Where did you get this? A rationale is given at [1], and

> The musl author doesn't believe programs should unload code. Therefore, you're not allowed to do it. Where did you get this? A rationale is given at [1], and it's basically: 1) dlclose() being a no-op is allowed by POSIX. 2) It's common for unloading and reloading libraries to trigger subtle/latent bugs, so making dlclose() a no-op leads to more reliable operation in the common case. 3) Managing thread-local storage in combination with unloading libraries is a complex problem, and arguably requires libc to either weaken error handling or leak memory. This is certainly consistent with an opinionated-standards-lawyer-curmudgeon view of the world, but it seems pretty far from just saying that you're not allowed to do it because you shouldn't. [1] https://wiki.musl-libc.org/functional-differences-from-glibc.html#Unloading-libraries https://wiki.musl-libc.org/functional-differences-from-glibc...

quotemstr 7y ago
Yet the bumblebee flies: other libc implementations successfully implement code unloading and no amount of pointing at the standard will make me okay with musl not implementing code unloading, especially when part of the rationale is that other people write buggy code. It's not the place of libc to break functionality because the author believes other programmers can't use that functionality correctly.
- wahern 7y ago
  Which ones? Last time I looked that list couldn't have included glibc, which while nominally supporting it had several, long-standing thread race bugs. The nexus of dynamic library loading and threading is a hot-spot for bugs in glibc.[1] Excluding an interface is better than providing a buggy one, IMO. [1] What glibc needs to do is finally merge libpthread into libc proper. The amount of stub functions, conditional logic, mutex reimplementation, and other chicanery glibc implements in an attempt to support runtime loading of libpthread[2] makes the code extremely difficult to navigate and debug. Which IME goes a long way toward explaining why there are years of unfixed races in glibc. [2] By runtime I mean loading libpthread as a dependency of a shared library where the main binary wasn't linked against libpthread.
  - quotemstr 7y ago
    > nominally supporting it had several, long-standing thread race bugs Name one. And yes, pthreads should just be part of libc. Separating them is artificial and awkward.
    - wahern 7y ago
      I'm lazy so it's not specific to dlclose and unloading, here's one for dlerror I submitted in 2015 and which is still open: https://sourceware.org/bugzilla/show_bug.cgi?id=18192 https://sourceware.org/bugzilla/show_bug.cgi?id=18192 I also point in that report to three other similar races which I didn't have the time to properly document (because, seriously, they're so numerous and the backlog so long, it's hard not to be cynical).[1] Look, I like glibc. I applaud their focus on ABI compatibility. glibc is burdened by tremendous technical debt, much of it blameless. And the project doesn't see the investment and attention it should. musl by contrast is a breath of fresh air in terms of correctness and simplicity, but they achieve that in part by taking a different approach than glibc. And that approach isn't necessarily better, it's just different, and they each have their costs. Pick your poison. [1] And I don't like drive-by complaints. If I submit a ticket for a project I try to back it with substantial evidence and suggested remedies, such as this Python2 + FIPS OpenSSL bug analysis I submitted last year: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1835135 https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/183... This is especially important for projects like glibc which are drowning in open bug reports.
      - quotemstr 7y ago
        > I'm lazy so it's not specific to dlclose and unloading, here's one for dlerror I submitted in 2015 and which is still open: https://sourceware.org/bugzilla/show_bug.cgi?id=18192 https://sourceware.org/bugzilla/show_bug.cgi?id=18192 Okay, so the only bug you've managed to come up with during a discussion of dlclose has nothing to do with dlclose. I am very much unconvinced that dlclose has fundamental correctness problems. > musl by contrast is a breath of fresh air in terms of correctness and simplicity, but they achieve that in part by taking a different approach than glibc. And that approach isn't necessarily better, it's just different, and they each have their costs. Yes, musl has a different approach. And this approach makes musl unsuitable for anything I might want to do. The maintainer is too opinionated and thinks he can dictate software architecture to libc users. The glibc maintainers don't think so, not as much.
jfkebwjsbx 7y ago
Pretty much 2) is saying "you're not allowed to do it because you shouldn't"...
- naasking 7y ago
  Actually, it seems pretty consistent with the original point that "the system serves programs, not the other way around". dlopen() being a no-op means the system is more reliable, so it sounds like the right choice.
mrpippy 7y ago
Apple has also considered making dlclose() a no-op on non-macOS (and the presentation is 3 years old so it may have happened by now) https://news.ycombinator.com/item?id=20229723 https://news.ycombinator.com/item?id=20229723
- saagarjha 7y ago
  No, dlclose still unloads the image if the reference count reaches 0: https://github.com/apple-open-source-mirror/dyld/blob/f033f5564c85c5cbfd24cf25e702e4bb0c2c39b4/dyld3/APIs.cpp#L795 https://github.com/apple-open-source-mirror/dyld/blob/f033f5...

quotemstr 7y ago

Yet the bumblebee flies: other libc implementations successfully implement code unloading and no amount of pointing at the standard will make me okay with musl not implementing code unloading, especially when part of the rationale is that other people write buggy code. It's not the place of libc to break functionality because the author believes other programmers can't use that functionality correctly.

wahern 7y ago
Which ones? Last time I looked that list couldn't have included glibc, which while nominally supporting it had several, long-standing thread race bugs. The nexus of dynamic library loading and threading is a hot-spot for bugs in glibc.[1] Excluding an interface is better than providing a buggy one, IMO. [1] What glibc needs to do is finally merge libpthread into libc proper. The amount of stub functions, conditional logic, mutex reimplementation, and other chicanery glibc implements in an attempt to support runtime loading of libpthread[2] makes the code extremely difficult to navigate and debug. Which IME goes a long way toward explaining why there are years of unfixed races in glibc. [2] By runtime I mean loading libpthread as a dependency of a shared library where the main binary wasn't linked against libpthread.
- quotemstr 7y ago
  > nominally supporting it had several, long-standing thread race bugs Name one. And yes, pthreads should just be part of libc. Separating them is artificial and awkward.
  - wahern 7y ago
    I'm lazy so it's not specific to dlclose and unloading, here's one for dlerror I submitted in 2015 and which is still open: https://sourceware.org/bugzilla/show_bug.cgi?id=18192 https://sourceware.org/bugzilla/show_bug.cgi?id=18192 I also point in that report to three other similar races which I didn't have the time to properly document (because, seriously, they're so numerous and the backlog so long, it's hard not to be cynical).[1] Look, I like glibc. I applaud their focus on ABI compatibility. glibc is burdened by tremendous technical debt, much of it blameless. And the project doesn't see the investment and attention it should. musl by contrast is a breath of fresh air in terms of correctness and simplicity, but they achieve that in part by taking a different approach than glibc. And that approach isn't necessarily better, it's just different, and they each have their costs. Pick your poison. [1] And I don't like drive-by complaints. If I submit a ticket for a project I try to back it with substantial evidence and suggested remedies, such as this Python2 + FIPS OpenSSL bug analysis I submitted last year: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1835135 https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/183... This is especially important for projects like glibc which are drowning in open bug reports.
    - quotemstr 7y ago
      > I'm lazy so it's not specific to dlclose and unloading, here's one for dlerror I submitted in 2015 and which is still open: https://sourceware.org/bugzilla/show_bug.cgi?id=18192 https://sourceware.org/bugzilla/show_bug.cgi?id=18192 Okay, so the only bug you've managed to come up with during a discussion of dlclose has nothing to do with dlclose. I am very much unconvinced that dlclose has fundamental correctness problems. > musl by contrast is a breath of fresh air in terms of correctness and simplicity, but they achieve that in part by taking a different approach than glibc. And that approach isn't necessarily better, it's just different, and they each have their costs. Yes, musl has a different approach. And this approach makes musl unsuitable for anything I might want to do. The maintainer is too opinionated and thinks he can dictate software architecture to libc users. The glibc maintainers don't think so, not as much.

jfkebwjsbx 7y ago

Pretty much 2) is saying "you're not allowed to do it because you shouldn't"...

naasking 7y ago
Actually, it seems pretty consistent with the original point that "the system serves programs, not the other way around". dlopen() being a no-op means the system is more reliable, so it sounds like the right choice.

mrpippy 7y ago

Apple has also considered making dlclose() a no-op on non-macOS (and the presentation is 3 years old so it may have happened by now) https://news.ycombinator.com/item?id=20229723 https://news.ycombinator.com/item?id=20229723

saagarjha 7y ago
No, dlclose still unloads the image if the reference count reaches 0: https://github.com/apple-open-source-mirror/dyld/blob/f033f5564c85c5cbfd24cf25e702e4bb0c2c39b4/dyld3/APIs.cpp#L795 https://github.com/apple-open-source-mirror/dyld/blob/f033f5...