| 15 Apr 2026 |
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 |
| 19 Apr 2026 |
| mdaniels5757 joined the room. | 19:20:41 |
| Lotte (it/its)/Cinny (she/her) θΔ& changed their profile picture. | 20:48:06 |
| 20 Apr 2026 |
antifuchs | All the lixcob talks I’ve seen recordings of so far are super great! Thanks for sharing them with all of us who couldn’t make it | 01:24:59 |
antifuchs | * All the lixcon talks I’ve seen recordings of so far are super great! Thanks for sharing them with all of us who couldn’t make it | 01:25:12 |
| picnoir changed their display name from Picnoir to picnoir. | 10:04:33 |
| 21 Apr 2026 |
| zoë (@blokyk) changed their display name from zoë (she/her) to zoë (@blokyk). | 03:08:40 |
zoë (@blokyk) | <disclamer>i'm not good at c++ / don't know much about the stdlib</disclaimer> i've seen an old FIXME by jade_ about getting rid of libutil::enumerate in favor of std::views::enumerate, but a lot of uses of it are for libutil::Generator, which don't seem like they can be easily substituted given Generator's unique semantics (notably nested generators, which i don't think is supported by any stdlib types?). so is that comment still relevant? or so, then do you plan to replace non-generator uses of it and keep Generator, or will Generator also be replaced at some point? | 09:33:08 |
zoë (@blokyk) | * <disclamer>i'm not good at c++ / don't know much about the stdlib</disclaimer> i've seen an old FIXME by jade_ about getting rid of libutil::enumerate in favor of std::views::enumerate, but a lot of uses of it are for libutil::Generator, which don't seem like they can be easily substituted given Generator's unique semantics (notably nested generators, which i don't think is supported by any stdlib types?). so is that comment still relevant? if so, then do you plan to replace non-generator uses of it and keep Generator, or will Generator also be replaced at some point? | 09:33:28 |
zoë (@blokyk) | * <disclamer>i'm not good at c++ / don't know much about the stdlib</disclaimer> i've seen an old FIXME by jade_ about getting rid of libutil::enumerate in favor of std::views::enumerate, but a lot of uses of it are for libutil::Generator, which don't seem like they can be easily substituted given Generator's unique semantics (notably nested generators, which i don't think is supported by any stdlib types?). so is that comment still relevant? if so, then do you plan to replace non-generator uses of it but keep it and Generator, or will Generator also be replaced at some point? | 09:33:48 |
Qyriad | LLVM libc++ doesn't have views::enumerate() yet :( | 09:34:36 |
Qyriad | Not sure about Generator though | 09:35:20 |
zoë (@blokyk) | oh i'm so dumb... i somehow misread the linked page about its stats ;-; | 09:35:48 |
zoë (@blokyk) | * oh i'm so dumb... i somehow misread the linked page about its status ;-; | 09:36:21 |
Qyriad | I did too the first time | 09:36:28 |
zoë (@blokyk) | it's surround by bright green Complete so it's easy to mistake | 09:36:55 |