3 ms·

I was talking about apt-get, try to do multiple installation from different terminal instances. Pretty sure it runs into a lock.

PaulHoule 1y ago
That's by design. Wouldn't want two of these to stomp on each other. It would be an interesting question to build something that can support some concurrency, for instance most of these times two projects are going to install different files and the only conflict might be in managing the actual package database. It would be like the time they took the giant lock out of the kernel, but that kind of thing is fraught. I remember a few years in the 2 series where we were getting crashes all the times under heavy load from concurrency bugs after they took out that lock.
- coolThingsFirst 1y ago
  Why is it by design? Concurrency is the bread and butter of modern computing.
  - PaulHoule 1y ago
    The easy way to solve concurrency problems is just put a lock on the whole thing. It is trivial to get that right. And if the actual demand for concurrency is low this is fine. A two processor machine doesn’t spend much time running the OS kernel so circa 2000 Linux had a giant kernel lock on the whole kernel. If you increase the number of CPUs though this became an increasing bottleneck and IBM did some really amazing work to make Linux scalable. Trouble is you now have to lock on smaller resources and the various combinations of things that could get locked increases the complexity exponentially. From the viewpoint of a user space developer the locking facilities under POSIX aren’t that good and move the tradeoff between “sometimes waiting for a lock” vs “dealing with data corruption” towards the former.
  - bigyabai 1y ago
    Not every package in modern computing can be parallelized. In a perfect world, building a Docker container or Python package takes a single step and happens entirely concurrently. But that's obviously unrealistic, every program has some order-of-operations even if it's as simple as creating some volumes or setting environment variables. If you try to run them out-of-order or simultaneously, the root is polluted and you have to start over again from scratch. All software packages are staged by-design. Linux does have solutions to this - Flatpak implements the macOS strategy of redundant static-linking, and Nix has an isolated dynamically-linked package manager that allows you to build and install packages concurrently. But both use a lot of disk space and aren't super intuitive to users that just want native versions of the programs they use.

PaulHoule 1y ago

That's by design. Wouldn't want two of these to stomp on each other. It would be an interesting question to build something that can support some concurrency, for instance most of these times two projects are going to install different files and the only conflict might be in managing the actual package database. It would be like the time they took the giant lock out of the kernel, but that kind of thing is fraught. I remember a few years in the 2 series where we were getting crashes all the times under heavy load from concurrency bugs after they took out that lock.

coolThingsFirst 1y ago
Why is it by design? Concurrency is the bread and butter of modern computing.
- PaulHoule 1y ago
  The easy way to solve concurrency problems is just put a lock on the whole thing. It is trivial to get that right. And if the actual demand for concurrency is low this is fine. A two processor machine doesn’t spend much time running the OS kernel so circa 2000 Linux had a giant kernel lock on the whole kernel. If you increase the number of CPUs though this became an increasing bottleneck and IBM did some really amazing work to make Linux scalable. Trouble is you now have to lock on smaller resources and the various combinations of things that could get locked increases the complexity exponentially. From the viewpoint of a user space developer the locking facilities under POSIX aren’t that good and move the tradeoff between “sometimes waiting for a lock” vs “dealing with data corruption” towards the former.
- bigyabai 1y ago
  Not every package in modern computing can be parallelized. In a perfect world, building a Docker container or Python package takes a single step and happens entirely concurrently. But that's obviously unrealistic, every program has some order-of-operations even if it's as simple as creating some volumes or setting environment variables. If you try to run them out-of-order or simultaneously, the root is polluted and you have to start over again from scratch. All software packages are staged by-design. Linux does have solutions to this - Flatpak implements the macOS strategy of redundant static-linking, and Nix has an isolated dynamically-linked package manager that allows you to build and install packages concurrently. But both use a lot of disk space and aren't super intuitive to users that just want native versions of the programs they use.