1. Forum
  2. Usenet
  3. LINUX.DEBIAN.PORTS.HURD

  • sem_open is coming!

    From Samuel Thibault@21:1/5 to All on Thu Dec 17 00:10:01 2020
    Hello,

    More and more packages were depending on a working sem_open() function
    (scipy, pandas, matplotlib, etc.) so I "implemented" it (basically
    copied over the nptl implementation), it will be in libc0.3 2.31-6 which
    is getting built.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey Walton@21:1/5 to sthibault@debian.org on Thu Dec 17 01:00:01 2020
    On Wed, Dec 16, 2020 at 6:02 PM Samuel Thibault <sthibault@debian.org> wrote:

    More and more packages were depending on a working sem_open() function (scipy, pandas, matplotlib, etc.) so I "implemented" it (basically
    copied over the nptl implementation), it will be in libc0.3 2.31-6 which
    is getting built.

    Forgive my ignorance... I thought semaphores were counted signals
    implemented by the OS so they can be used across processes.

    I don't believe libc should be in the business of sharing data across processes.

    In fact, regarding userland sharing, a GNU_SHARED data section in an
    elf binary will cause it to fail an audit or produce a finding.
    Processes should not be sharing data like that because a corruption in
    one process affects another process.

    Jeff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Thu Dec 17 01:20:01 2020
    Jeffrey Walton, le mer. 16 déc. 2020 18:55:53 -0500, a ecrit:
    On Wed, Dec 16, 2020 at 6:02 PM Samuel Thibault <sthibault@debian.org> wrote:
    More and more packages were depending on a working sem_open() function (scipy, pandas, matplotlib, etc.) so I "implemented" it (basically
    copied over the nptl implementation), it will be in libc0.3 2.31-6 which
    is getting built.

    Forgive my ignorance... I thought semaphores were counted signals
    implemented by the OS so they can be used across processes.

    If you implement them in the OS only they would be performing very
    poorly. You don't want to pay the user/kernel switch cost at each
    sem_wait/post operation. The OS does provide the basic feature for
    "blocking", indeed, read the "futexes are tricky" paper from Ulrich
    Drepper for more information.

    I don't believe libc should be in the business of sharing data across processes.

    Your mileage may vary.

    Not providing the feature means excluding the availability of
    applications currently requiring it.

    Processes should not be sharing data like that because a corruption in
    one process affects another process.

    Sharing data is a complex matter, indeed. That doesn't mean we shall not implement support for it.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)