| 15 Apr 2026 |
ShalokShalom | In case someone is interested into arguments why semantic versioning is broken in itself, listen to Rich Hickey. | 13:15:02 |
ShalokShalom | * In case someone is interested into arguments why semantic versioning is broken in itself, listen to Rich Hickey. | 13:15:14 |
piegames | Off-topic, please | 13:20:12 |
Sergei Zimmerman (xokdvium) | Is Lix going to go with a zygote fork helper? | 18:15:09 |
Sergei Zimmerman (xokdvium) | To mitigate the slow fork times? | 18:15:48 |
raitobezarius | well, lix has already very fast fork times now | 18:16:45 |
raitobezarius | but vfork is dangerous | 18:16:49 |
raitobezarius | so if we can have the speed and the safeness (aka zygote fork helper), that'd be great | 18:17:02 |
raitobezarius | but lower priority | 18:17:05 |
Sergei Zimmerman (xokdvium) | How did you achieve that? It's using the plan old fork() if I read the code correctly and that's still slow when there is a lot of memory allocated | 18:19:58 |
raitobezarius | vfork | 18:20:51 |
raitobezarius | grep inVFork | 18:21:03 |
raitobezarius | in the codebase | 18:21:04 |
raitobezarius | /**
* runs a callback in a vforked child process that shares its address space with
* the current process. the child behaves much like a thread as a result and the
* callback must not make changes to process memory that we cannot undo from the
* parent, otherwise we may leak memory or fully trash the parent address space.
*
* NOTE: see `asVFork` for safety information regarding credentials and signals.
*
* throws an exception if the child exec's or otherwise doesn't return a result.
*/
static auto inVFork(int flags, auto fn)
{
auto [pid, result] = asVFork(flags, fn);
if (result) {
return std::move(result->value());
} else {
throw Error("vfork child unexpectedly did not produce a value");
}
}
this is the entrypoint of the magic
| 18:21:26 |
raitobezarius | some plain old fork() might be used in other places | 18:21:43 |
Sergei Zimmerman (xokdvium) | Ah that's for the sandboxing setup, I see. I was looking at libexec helpers | 18:21:50 |
raitobezarius | but wrt to derivation builds, the overhead is around 2µs ? | 18:21:59 |
raitobezarius | getting lower would be nice ofc | 18:22:44 |
raitobezarius | but not urgent | 18:22:49 |
raitobezarius | it is now possible to build 1M derivations reasonably | 18:23:00 |
| 16 May 2024 |
| zrsk joined the room. | 13:54:49 |
samrose | In reply to @lunaphied:lunaphied.me I think there were a few CLs on the Gerrit but nothing being actively worked The other thing that I could do if it helps is test things and try to find bugs. I did do some C++ work in the past, but may lack the time to do it justice here at least for about 30 days or so | 15:55:29 |
Qyriad | we are not in any rush 🙂 | 17:20:53 |
samrose | Would it help to also test out the existing Lix code and try to find issues/bugs etc? | 17:23:21 |
Qyriad | absolutely | 17:23:41 |
samrose |
- how do people feel about the existing test suite that comes along with nix source code or Lix?
| 17:23:48 |
Qyriad | it's pitiful | 17:24:10 |
samrose | heh | 17:24:16 |
raitobezarius | expanding it is cool | 17:24:23 |
raitobezarius | writing new tests for builtins which are not tested | 17:24:30 |