feat(v2): init code

[Sobeston]

Working

• Child process initialisation
• Child process exit handling
  • fmt printing error return traces
  • fmt printing panics traces
• memory sharing
• high level of security
  • regions are shared only as-needed, with write perms as-needed
  • mseal to stop our shared regions from being later modified by anyone
  • closing out all FDs, except for an optional stderr
  • seccomp to ban almost all syscalls
    • write syscalls only allowed on single provided stderr FD
    • intending that these will be per-service once we have some
• segfault/signal handling

Example output:

$ zig build run --summary all
Starting Service `Logger`, pid: 1901329
Starting Service `Prng`, pid: 1901330
logger: 00000000000000000000000000000000
logger: ad6703e88ed12d8395f17166821006b7
logger: 0382af77b8d42e52f5bf86b75dadc6b0
logger: 4ce1fd919404aef24d94c06456cc20c3
logger: 6c0fcbf0b162f6ff71fd1f0b03aeeb8a
logger: 11b54ffeff213f7c8b17a6c5018cc137
logger: fdd75f4d435782edf1f243f33f526245
logger: 8a7a8b1e23f118a13f6df9fc8a7aadb7
logger: 6d6c7854b71d508ee6a56f7d74b32499
logger: fc3d696b8f8a4066d029d49879e11da7
logger: finished, time to exit
Service `Logger` (pid: 1901329) exited with error: TimeToExit
Error trace:
/[..]/sig/v2/src/services/logger.zig:28:5: 0x119a5b5 in main (logger.zig)
    return error.TimeToExit;
    ^

Build Summary: 9/9 steps succeeded
run success
└─ run exe sig-init success 100ms MaxRSS:7M
   ├─ compile exe sig-init Debug native cached 7ms MaxRSS:36M
   │  ├─ WriteFile cached
   │  ├─ compile lib svc_logger Debug native cached 7ms MaxRSS:34M
   │  ├─ WriteFile cached
   │  ├─ compile lib svc_prng Debug native cached 7ms MaxRSS:36M
   │  ├─ compile lib svc_logger Debug native (reused)
   │  └─ compile lib svc_prng Debug native (reused)
   └─ install cached
      └─ install sig-init cached
         └─ compile exe sig-init Debug native (+6 more reused dependencies)

What a minimal service looks like:

const std = @import("std");
const start = @import("start");

comptime {
    _ = start;
}

pub const name: []const u8 = "prng";
pub const _start = {};
pub const panic = start.panic;

pub const ReadWrite = struct {
    prng_state: *std.Random.Xoroshiro128,
};

pub fn main(writer: *std.io.Writer, rw: ReadWrite) !noreturn {
    _ = writer;

    rw.prng_state.seed(123);
    while (true) rw.prng_state.seed(rw.prng_state.next());
}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
see 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dnut]

Please choose a different name. main has a very specific meaning and this does not conform to the pattern. My preference would be run but there are many other acceptable options.

some ideas:

• run
• entrypoint
• run_service
• service_entry
• service_main

[Sobeston]

main has a very specific meaning and this does not conform to the pattern.

I don't really agree with this - every programming environment has its own idea of what main means; even zig has multiple kinds of main functions.

We're basically opting out of Zig's start.zig and using our own startup code instead. So I think the name reflects well?

[dnut]

Sure we could reinterpret the word main because we have a different startup, but I just don't see the point. I only see potential for confusion. I don't see any compelling reason why the word main is better than any of the other names I've suggested.

[yewman]

I prefer 'main'. What specific meaning are you referring to that does not conform to this pattern? In this context it is the entry point to a service which is intended to run as isolated process. Personally I don't see what is confusing about it or how any of the suggested names are an improvement

[dnut]

The problem is simply that it's a source of confusion. The word "main" is almost always used make it so the file can be compiled to a standalone binary executable using the standard build process. That's not what's going on here. I don't see why you would use the word "main" to mean something different than what it's normally used for, when you have the freedom to select any name, and there are actually more descriptive names you could choose. This already caused confusion when this was demoed to the team with multiple people making wrong assumptions about how this code works because of this name. I don't want to use a name that I know is going to confuse people when there are equally valid alternatives that are less confusing.

[jbuckmccready]

I'll pitch in my opinion:

main as a symbol, by default, in most (overwhelming majority?) programming languages is the the executable entry point when your code is compiled and linked. If main isn't the entry point for the executable then I don't think we should use main, it can only add confusion.

Using service_main, service_entry, {service_name}_entry etc. will communicate the same thing, and eliminate any possible confusion to those coming from other projects or languages.

[yewman]

I don't mind. Anything works

[dnut]

I feel strongly that this should not be named main. I'm fine with a variety of other options.

[dnut]

let's avoid this name too. also why does this function need to be separate from the function above?

[dnut]

I think this belongs in the root .gitignore

[Sobeston]

it's fine to have multiple, conceptually this is a different project, this follows the same pattern as the conformance folder

[dnut]

I understand it's fine to have multiple, but if the root project had the same lines in .gitignore, then adding these lines here would have no effect. It's in the same monorepo so it's not realistic to try to create a .gitignore as if this is an isolated repo. I don't see the benefit to this redundancy.

[dnut]

I don't have a strong feeling that we need to remove this file. My main concern is that we have inconsistency in our approach and it feels slightly chaotic. In here, and in conformance, we ignore these names at any nested level, but in the root we only ignore them if they exist at the root level.

My thought is that the approach here is actually good: we shouldn't be committing folders called .zig-cache or zig-out regardless of where they are. The problem is that it's only being applied locally in a few places. I'd rather use this as the general approach. So I would change the repo root's .gitignore to follow this same pattern. Once we do that, there's not really a need for this file. But deleting this file isn't necessary my goal here, so I'm open to leaving it if you see some good reasoning for it to exist.