Explain .threads = ?, .workers = ?

[iacore]

I was able to use

    zap.start(.{
        .threads = 1,
        .workers = undefined,
    });

without an issue. This is mentioned in https://facil.io/0.7.x/index. What does the workers field do?

[jeroenflvr]

From https://facil.io/0.7.x/fio#running-facil-io

• threads: The number of threads to run in the thread pool.
• workers: The number of worker processes to run (in addition to a root process)

More specifically:

"If the other option (i.e. .workers when setting .threads) is zero, it will be automatically updated to reflect the option's absolute value. i.e.: if .threads == -2 and .workers == 0, than facil.io will run 2 worker processes with (cores/2) threads per process."

[renerocksai]

I agree, we should put doc comments to pub fn start(); thx, @jeroenflvr for looking it up.

But now for something more important:

        .workers = undefined,

NEVER do this!!!!

It will set .workers to 0 in debug builds if you're lucky, but is likely undefined in release. Meaning, one time it might start 123 workers and the next time 250.

undefined in Zig means something different than you may assume. It does not mean: "I don't want to define this, so please take a default value."

If that's what you wanted to express, it would be: .{ .threads = 1 }: omitting .workers, so Zig can take the default value.

In Zig, undefined is NOT a value. You cannot check if anything is undefined, like: "if it's undefined, then set it to 5".

undefined means: just reserve memory for a variable, but DON'T write to it, don't initialize it. I promise, I will initialize it later:

var x : u8 = undefined;

// x can have any value now, from 0 to 255

// ... do some other stuff that does not involve reading from x ...

x = 1;

// now x has a defined value, we kept our promise to initialize it later

Above example is probably more easy to understand. Now imagine this:

fn foo(struct{ a: u8, b: u8}) void {
    std.log.debug("a={d}, b={d}", .{a, b});
}

test foo {
    // now call foo with **random, uninitialized garbage**
    foo(.{ .a = undefined, .b = undefined });
}

That is not what undefined was made for. You basically pass garbage for a and b if you do that.

// now with default values
fn foo(struct{ a: u8 = 0, b: u8 = 0}) void {
    std.log.debug("a={d}, b={d}", .{a, b});
}

test foo {
    foo(.{                 .b = 3});   // OK: a will take the default
    foo(.{ .a = undefined, .b = 3});   // CRAP: a will be "random garbage"
}

[iacore]

Running facil.io

The facil.io IO reactor can be started in single-threaded, multi-threaded, forked (multi-process) and hybrid (forked + multi-threads) modes.

In cluster mode (when running more than a single process), a crashed worker process will be automatically re-spawned and "hot restart" is enabled (using the USR1 signal).

I assume that using process is better than threads (on Linux it's all process with or without memory sharing).

[renerocksai]

General assumptions are always bad. I do not agree that "using process" is better than threads, in general. "better" in terms of what?

If you use more than one worker process, you'll have to come up with IPC to "share state" between processes.

In complex "apps', I always used 1 worker with n threads, to get that auto-mem-sharing. I favored using sth like a hashmap in RAM over using some form of persistence just to be able to access data from multiple workers.

If all you do is serving static content or even files, so all requests are independent of each other, then using multiple worker processes is an option. But not necessarily the better option. I would strongly advise taking some actual, accurate, measurements or observations before assuming.

[iacore]

This is off-topic, but I'm willing to trade memory for reliability.

[renerocksai]

I agree it's off-topic. But now it seems you suggest processes provide higher reliability than threads? In the context of facil.io / zap? Do you know that? Or do you assume that? What do you even mean with "reliability"? (These are all rhetorical questions, I don't want to go into a debate. Especially here, and I don't have time for it anyway. 😄).

I just don't want to leave such statements unchallenged here. Especially with other newbies reading them, giving the topic of the issue.

I just don't agree. I am not arguing for threads. I am arguing against such condensed pieces of wisdom that leave out too much to be applicable in general.