[chubot]

FWIW I also started writing a init-like server in Go. One thing I ran into was that Go's APIs sort of coerce you into having an extra thread per process. runsit also has this issue. See line 489 of runsit.go, pasted below.

You can do it non-portably in Go by using os.ForkExec and Wait4(-1). The portable exec package assumes you will call Wait(pid), and not Wait(-1), which basically implies using a thread per process. Go's runtime isn't magic -- if you call libc/syscall wait(), an entire thread will be blocked, and the runtime can't use it for anything else. In this case this is the lifetime of an entire process, which is forever for server processes.

I'm pretty sure nobody would use a real PID 1 that burned a thread per process (systemd, upstart, etc.). But yes, for most use cases, in the grand scheme of things, it's probably not a big deal. I suppose Linux has an O(1) scheduler, although I'm not quite sure how this affects scheduling (interested in any comments).

But this goes to show that portable APIs are awkward and obscure for low level code. Better to use raw Unix APIs for something like an init server. Python and Java have similar problems.

IMO all interesting code nowadays is POSIX-like, so we should drop the pretension of portability and simplify our lives. Unix works.

    // run in its own goroutine
    func (in *TaskInstance) awaitDeath() {
      in.waitErr = in.cmd.Wait()  // ties up an OS thread for the lifetime of a process
      ...  
    }

[pedrocr]

> I suppose Linux has an O(1) scheduler

Actually not anymore. The current CFS scheduler is no longer O(1) but O(logN):

https://en.wikipedia.org/wiki/Completely_Fair_Scheduler

[robryk]

I wonder if it would make sense to make a "child poller" akin to the net poller:

Have one goroutine loop forever:

  * wait for SIGCHLD
  * take the childlock
  * do nonblocking Wait() until no unwaited child remains
  * release the childlock

The childlock would need to be taken for reading by os.Process.Kill and when a syscall that takes a PID of a child is called (after taking it we'd need to verify that the process we intend to touch isn't already dead).

[chubot]

Yes, you can do that. As mentioned, it's not portable (which is fine with me).

However, you don't need to use goroutines (or threads). You do it as you would in C (and how all real PID 1 systems are written) -- with a single thread that starts processes, receives signals, and reaps children in a non-blocking fashion.

This style of program -- a program that needs to simultaneously wait for child processes/signals and fd events -- is quite awkward in Unix, but it definitely works when you get the idea.

To wait on a fd and a signal in a single threaded program, you would use the "self pipe trick" in classic Unix. In Linux, you can ask for a signal to be delivered over a file descriptor with fdsignal(). But AFAICT there is no real reason, and portability across Unix IS a good thing IMO (but not portability to completely different OS's like Windows; in that case I would write a completely separate program using their native APIs).

node.js actually does a great job making this API easy and efficient. It is probably the only runtime (Python/Ruby/JVM/etc.), that doesn't suffer from this problem doing "async processes" (i.e. a complement to async networking).

[burke]

We have an init process that runs inside docker containers, and we took a bit of a different route, in listening on SIGCHLD and then doing non-blocking Wait4(0,...) until there are no more children to reap:

https://gist.github.com/burke/1c105378ac0629b39485

[chubot]

I think that is basically the same thing. I haven't used Wait4(0), but it looks like it is the same as Wait4(-1), as long as you don't change the process group ID of any of the children?

In any case, you are not calling Wait4(<specific PID>), which is what implies the thread per process.

[zemo]

A goroutine is not a thread. That only ties up that one goroutine.

[chubot]

Your first statement is true; the second isn't.

Re-read what I wrote. If that doesn't convince you, then download and run the code. Run "pstree" on it and observe how many child processes and threads there are. You'll learn something useful about the relationship of the Go runtime to the OS.

[zimbatm]

A thread is created for blocking syscalls. I don't know if it's a syscall under the hood here but he might be talking about that.