!lymvtcwDJ7ZA9Npq:lix.systems

Lix Development

428 Members
(Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel.141 Servers

Load older messages


SenderMessageTime
15 Apr 2026
@raitobezarius:matrix.orgraitobezariuswell, lix has already very fast fork times now18:16:45
@raitobezarius:matrix.orgraitobezariusbut vfork is dangerous18:16:49
@raitobezarius:matrix.orgraitobezariusso if we can have the speed and the safeness (aka zygote fork helper), that'd be great18:17:02
@raitobezarius:matrix.orgraitobezariusbut lower priority18:17:05
@xokdvium:matrix.orgSergei 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 allocated18:19:58
@raitobezarius:matrix.orgraitobezariusvfork18:20:51
@raitobezarius:matrix.orgraitobezarius grep inVFork 18:21:03
@raitobezarius:matrix.orgraitobezariusin the codebase18:21:04
@raitobezarius:matrix.orgraitobezarius
/**
 * 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:matrix.orgraitobezariussome plain old fork() might be used in other places18:21:43
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)Ah that's for the sandboxing setup, I see. I was looking at libexec helpers18:21:50
@raitobezarius:matrix.orgraitobezariusbut wrt to derivation builds, the overhead is around 2µs ?18:21:59
@raitobezarius:matrix.orgraitobezariusgetting lower would be nice ofc18:22:44
@raitobezarius:matrix.orgraitobezariusbut not urgent18:22:49
@raitobezarius:matrix.orgraitobezariusit is now possible to build 1M derivations reasonably18:23:00
19 Apr 2026
@mdaniels5757:matrix.orgmdaniels5757 joined the room.19:20:41
@lotte:chir.rsLotte (it/its)/Cinny (she/her) θΔ& changed their profile picture.20:48:06
20 Apr 2026
@antifuchs:asf.computerantifuchsAll 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 it01:24:59
@antifuchs:asf.computerantifuchs* 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 it01:25:12
@picnoir:alternativebit.frpicnoir changed their display name from Picnoir to picnoir.10:04:33
21 Apr 2026
@blokyk:matrix.orgzoë (@blokyk) changed their display name from zoë (she/her) to zoë (@blokyk).03:08:40
@blokyk:matrix.orgzoë (@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
@blokyk:matrix.orgzoë (@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
@blokyk:matrix.orgzoë (@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:katesiria.orgQyriad LLVM libc++ doesn't have views::enumerate() yet :( 09:34:36
@qyriad:katesiria.orgQyriad Not sure about Generator though 09:35:20
@blokyk:matrix.orgzoë (@blokyk) oh i'm so dumb... i somehow misread the linked page about its stats ;-; 09:35:48
@blokyk:matrix.orgzoë (@blokyk) * oh i'm so dumb... i somehow misread the linked page about its status ;-; 09:36:21
@qyriad:katesiria.orgQyriad I did too the first time 09:36:28
@blokyk:matrix.orgzoë (@blokyk) it's surround by bright green Complete so it's easy to mistake 09:36:55

Show newer messages


Back to Room ListRoom Version: 10