@ai-ecoverse/slicc-kernel 1.73.3 → 1.74.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -270,14 +270,14 @@ The module's default export (or its `main` export) is called with a context and
270
270
  - `/dev`, in `open`, `fs` and their `sync` forms, as a WASI or Emscripten program sees it, with the same modes and owners as under `users`: `null`, `zero`, `full`, `random`, `urandom` and `tty` (character devices, `0666`, root's), `stdin`, `stdout` and `stderr` (links to `/proc/self/fd/0`, `1`, `2`), `fd` (a link to `/proc/self/fd`, so `/dev/fd/N` is descriptor N) and the kernel's terminals `/dev/ttyN` and `/dev/pts/N` (with users on, owned by the session's user or the master's opener, `0620`). `/dev/shm` and `/dev/ptmx` aren't there. `stat` through `/dev/stdin`, `/dev/stdout` or `/dev/fd/N` describes the program's own descriptor (the file it is redirected to, a pipe, a terminal), `readlink` of `/dev/fd/N` names it (`pipe:[N]` and `socket:[N]` for a pipe or a socket), and a closed descriptor is `ENOENT`. Opening a device gives a kernel descriptor on it; opening `/dev/std*` or `/dev/fd/N` opens the file again with the flags asked for when the descriptor is on a file (as Linux reopens `/proc/self/fd/N`, so `append` appends and `truncate` truncates), and otherwise duplicates the descriptor; `/dev/tty` is the program's controlling terminal (`ENXIO` without one); and `/dev/ttyN` and `/dev/pts/N` are opened by name through the kernel, so a terminal that isn't the user's is `EACCES` under `enforce`. A file on anything but a regular file reads and writes as a stream (the position is ignored) and only in the directions it was opened for (`EBADF` otherwise), its `size()` is 0 and `truncate` is `EINVAL`. `readFile` reads a device or a descriptor to its end, up to 64 MiB, and fails with `EFBIG` past that (where Node's `readFile` throws `ERR_FS_FILE_TOO_LARGE`), so `readFile('/dev/zero')` fails instead of hanging, while a bounded `read` of it works. Other paths pay only a prefix check: they make the same kernel calls as before. Creating, removing or renaming names in `/dev` goes to the root file system as before;
271
271
  - `signals`: `on(signal, handler)` catches a signal (by number or as `'SIGINT'`), `ignore(signal)` ignores it and `reset(signal)` restores its default action. A call blocked in a read or write is restarted after a handler runs; signals without a handler keep their default actions, so an uncaught `SIGINT` ends the program with 130 and `SIGKILL` always does;
272
272
  - `sync`: `read`, `write`, `close`, `open` (whose files' methods are synchronous too) and `fs`, made synchronously, for code that cannot `await`, such as a compiled program's file system or a `readFileSync`. A synchronous call holds the worker until the kernel answers, so nothing else of the program runs meanwhile, timers and callbacks included; a signal that arrives during a blocked read or write runs its handler, and the call is then restarted. Descriptors are shared with the rest of the context, so a file opened with `sync.open` can be closed with `close`, and the other way around; `sync.run` and `sync.exit` are described next;
273
- - `sync.run({ argv, env, cwd, input, stdin, stdout, stderr, maxBuffer, timeout, killSignal })` runs a command to its end and answers `{ pid, status, signal, stdout, stderr, error }`, as Node's `spawnSync` does. It suits `execSync`, `spawnSync` and `execFileSync`. The kernel does the whole run while the program's worker waits; other processes go on.
273
+ - `sync.run({ argv, env, cwd, pgid, session, input, stdin, stdout, stderr, maxBuffer, timeout, killSignal })` runs a command to its end and answers `{ pid, status, signal, stdout, stderr, error }`, as Node's `spawnSync` does. `pgid` and `session` work as for `spawn` below; a group that doesn't exist or is another session's answers `error: { code: 'ESRCH' }` or `'EPERM'`, and a bad option throws `EINVAL`. It suits `execSync`, `spawnSync` and `execFileSync`. The kernel does the whole run while the program's worker waits; other processes go on.
274
274
  - Each stdio is `'pipe'` (the default), `'ignore'`, `'inherit'` (the program's own, a terminal included), or one of the program's descriptors by number, which the child gets as it is (two slots on one descriptor share it, so their writes keep their order). `stderr: 'stdout'` sends stderr to whatever stdout is, the stdout capture included, in the order the child writes. With `'pipe'`, stdin gets `input` (bytes, or a string as UTF-8) and then its end, so `cat` stops; `stdout` and `stderr` come back as bytes and are absent for the other choices. Both are drained while the child runs, so a child that writes more than a pipe holds never stalls. As in Node, the call returns once the child has exited and every captured stream has reached its end, so output a background grandchild writes later is still collected; `timeout` bounds that wait too, so, as with Node's `spawnSync`, a run blocks for as long as a background process keeps a captured stream open unless `timeout` is set; pass one for a command that may leave something in the background. Once the outcome is decided (the end of output, an overflow or a timeout), the captured streams are closed, so a writer still left on them gets `EPIPE` (and `SIGPIPE`) instead of running on.
275
275
  - `status` is the exit status, or `null` with `signal` set when a signal ended the child. A non-zero status is not an error. A command that cannot start (it does not exist, or is not executable) answers `error: { code: 'ENOENT' }` (or the errno), `status: null` and `pid: 0` instead of throwing.
276
276
  - More than `maxBuffer` bytes on `stdout` or `stderr` (1 MiB by default) sends the child `killSignal` (`SIGTERM` by default), keeps the first `maxBuffer` bytes, and answers `error: { code: 'ENOBUFS' }`. The kernel keeps at most 64 MiB of each stream whatever `maxBuffer` says, `Infinity` included, since the buffers live in the kernel worker that all processes share. `timeout` (ms) sends `killSignal` when it runs out and answers `error: { code: 'ETIMEDOUT' }`. A child that ignores `killSignal` is still waited for, as in Node.
277
277
  - The child is in the program's process group, so `^C` reaches it. The kernel reaps it, so it leaves no zombie, and its CPU time counts as the program's children's. A signal the program catches does not cut the run short; its handler runs when the call returns. A signal that kills the program kills it as usual;
278
278
  - `sync.kill(pid, signal)`, a synchronous `kill`. When the signal reaches the program itself (its own pid, `0` for its process group, or `-pgid` of its own group) and its action is to end the program (no handler, not ignored), the call never returns: the program's writes reach their descriptors and its terminal modes are put back, as for `sync.exit`, then the rest of the group is signalled and the program ends by the signal, so a parent's `wait` and `sync.run` report `signal`, as Node does for `process.kill(process.pid)`. A signal with a handler runs it when the call returns, an ignored one does nothing, and a stop signal stops the program. A signal whose default action dumps core (`SIGQUIT`, `SIGABRT`, `SIGSEGV`, …) ends it the same way; the kernel writes no core and sets no core flag in the wait status. `-1` signals every process the program may signal except itself and pid 1, as on Linux, and returns (`ESRCH` when there was none). Without users, every process runs as root, so `kill -9 -1` from any program ends every other process; with users it reaches only what the sender may signal (its own uid's processes, or all of them as root);
279
279
  - `sync.exit(status)`, which ends the process at once, as Node's `process.exit()` does: no `catch`, `finally`, microtask, timer or signal handler runs after it, because the call never returns. First the writes the program has made reach their descriptors, in order (a broken pipe drops the rest for that descriptor), and terminal modes the program set with `tty` are put back. Then the process ends the way any exit does: its descriptors are closed and written back, its parent gets `SIGCHLD`, and `wait` reports `status`. Children keep running. A JS program has no threads of its own (`Worker` is withheld), so nothing of it outlives the call. `exit(status)` (below) unwinds instead, so the program's `catch` and `finally` blocks run;
280
- - `spawn({ argv, env, cwd, stdin, stdout, stderr })` starts a command (found as `kernel.run` finds it) as a child process and resolves with `{ pid, stdin, stdout, stderr, wait(), kill(signal) }`. Each stdio is `'inherit'` (the default: the program's own), `'pipe'` (a web stream on a kernel pipe), `'null'`, or one of the program's descriptors. `env` is the child's whole environment (the program's by default), and `cwd` defaults to the program's. A command that does not exist rejects with `ENOENT`;
280
+ - `spawn({ argv, env, cwd, pgid, session, stdin, stdout, stderr })` starts a command (found as `kernel.run` finds it) as a child process and resolves with `{ pid, stdin, stdout, stderr, wait(), kill(signal) }`. Each stdio is `'inherit'` (the default: the program's own), `'pipe'` (a web stream on a kernel pipe), `'null'`, or one of the program's descriptors. `env` is the child's whole environment (the program's by default), and `cwd` defaults to the program's. The child is in the program's process group and session, as after `fork` (Node's `detached: false`), so the terminal's `^C` and `^Z` reach it along with the program. `pgid: 0` makes it lead a new group in the program's session, set before it runs, so a `kill(-pid)` right after the call reaches it and everything it starts (`npx`, then `node`); on the program's terminal that group is in the background, so a read from the terminal stops it with `SIGTTIN` (`EIO` when it ignores `SIGTTIN`), as on Linux. `pgid: N` joins group N, which must be in the program's session: `EPERM` for another session's group, `ESRCH` when there is none. `session: true` makes it lead a new session and a new group (`setsid`, what Node's `detached: true` does on POSIX): its pid is its `pgid` and its `sid`, it has no controlling terminal (`/dev/tty` is `ENXIO`) and the terminal's keys don't signal it. `session` together with `pgid`, or a `pgid` that isn't a non-negative integer, is `EINVAL`. A command that does not exist rejects with `ENOENT`;
281
281
  - `wait(pid)` resolves with `{ status }` once a child ends, or `{ status: 128 + signal, signal }` when a signal ended it, without blocking the program; `kill(pid, signal)` signals any process, by number or as `'SIGTERM'` (the default);
282
282
  - `sudo(args)`, what the [`sudo`](#sudo) command calls: `args` are its arguments after `sudo`, and it resolves with `{ pid }`, the command the kernel started as the program's child, to `wait` for; `{ run }`, an argv to run as the caller (with `users: 'off'`); `{ list }`, the text of `sudo -l`; or `{ error, errno }`, the message to print;
283
283
  - `net`: `listen({ port, host, backlog })` and `connect({ host, port, signal })` (`host` defaults to `127.0.0.1`) on the kernel's loopback, the same sockets WASIX programs use, so a JS server is reached by other processes, by the page as `<port>.kernel.localhost` (`loopbackFetch`, `dial`) and by attached clients. A listener has its `port` (as bound, so port `0` picks a free one), `accept({ signal })`, `close()` and `for await` over its connections. A connection has `local` and `remote` addresses, `readable` and `writable` web streams (closing the writable shuts down the sending side, so the peer reads the end), and `close()`. The loopback is IPv4 (`127.0.0.1` by default, or `0.0.0.0`), so an IPv6 host such as `::1` fails with `EADDRNOTAVAIL` for both `listen` and `connect`, and binding and connecting fail as they would for a WASIX program (`EADDRINUSE`, `ECONNREFUSED`, `EADDRNOTAVAIL`). A blocked accept, read or write waits without holding anything in the kernel, so aborting it or closing the socket leaves nothing behind. A write to a connection the peer closed fails with `EPIPE` and no `SIGPIPE`;
@@ -11175,7 +11175,14 @@ async function runChild(req, deps) {
11175
11175
  ];
11176
11176
  try {
11177
11177
  pid = await deps.children.spawn(
11178
- { file: req.file, argv: req.argv, env: req.env, cwd: req.cwd },
11178
+ {
11179
+ file: req.file,
11180
+ argv: req.argv,
11181
+ env: req.env,
11182
+ cwd: req.cwd,
11183
+ ...req.pgid !== void 0 ? { pgid: req.pgid } : {},
11184
+ ...req.session ? { session: req.session } : {}
11185
+ },
11179
11186
  stdio
11180
11187
  );
11181
11188
  } catch (e) {
@@ -12128,8 +12135,9 @@ var WasmProcess = class {
12128
12135
  return "deliver";
12129
12136
  }
12130
12137
  async spawn(req) {
12131
- const { file, argv, env, cwd, stdio, inherit: inherit2, exec } = req;
12132
- const spawned = { file, argv, env, cwd, ...exec ? { exec } : {} };
12138
+ const { file, argv, env, cwd, stdio, inherit: inherit2, exec, pgid, session } = req;
12139
+ const group = { ...pgid !== void 0 ? { pgid } : {}, ...session ? { session } : {} };
12140
+ const spawned = { file, argv, env, cwd, ...group, ...exec ? { exec } : {} };
12133
12141
  const pid = await this.children.spawn(spawned, stdio, inherit2);
12134
12142
  if (!exec) return pid;
12135
12143
  if (this.killed) void Promise.allSettled([this.options.kill?.(pid, SIG.KILL)]);
@@ -13423,6 +13431,9 @@ var JobTable = class {
13423
13431
  member.pgid = pgid;
13424
13432
  member.sid = sid;
13425
13433
  }
13434
+ lead(pid) {
13435
+ this.member(pid).pgid = this.idOf(pid);
13436
+ }
13426
13437
  pgidOf(pid) {
13427
13438
  return this.members.get(pid)?.pgid;
13428
13439
  }
@@ -16408,7 +16419,7 @@ var Launcher = class {
16408
16419
  start(req) {
16409
16420
  this.sampling();
16410
16421
  if (req.pgid !== void 0 && this.jobs.sessionOf(req.pgid) === void 0) {
16411
- throw fsError("ESRCH", `no process group ${req.pgid}`);
16422
+ throw new SpawnError("ESRCH");
16412
16423
  }
16413
16424
  const pid = this.nextPid++;
16414
16425
  const stack = this.stackFor(req.tag);
@@ -16483,6 +16494,8 @@ var Launcher = class {
16483
16494
  this.jobs.add(pid, req.ppid, (sig) => handle.signal(sig), terminal);
16484
16495
  if (req.exec && req.ppid !== void 0) this.jobs.exec(req.ppid, pid, true);
16485
16496
  if (req.pgid !== void 0) this.jobs.join(pid, req.pgid);
16497
+ if (req.group === "lead") this.jobs.lead(pid);
16498
+ if (req.group === "session") this.jobs.setsid(pid);
16486
16499
  this.described.set(pid, {
16487
16500
  argv: [req.argv0, ...req.args],
16488
16501
  tty: terminal?.name ?? null,
@@ -16644,6 +16657,11 @@ var Launcher = class {
16644
16657
  await fds.closeAll();
16645
16658
  throw new SpawnError("EACCES");
16646
16659
  }
16660
+ const group = this.childGroup(ppid, req);
16661
+ if (typeof group === "string") {
16662
+ await fds.closeAll();
16663
+ throw new SpawnError(group);
16664
+ }
16647
16665
  const cred = grant ? grant.cred : this.credOf(ppid);
16648
16666
  const scope = grant ? "" : await this.scopeOf(cred.euid);
16649
16667
  const planned = await this.plan(req.file, req.argv, req.cwd, scope);
@@ -16670,6 +16688,7 @@ var Launcher = class {
16670
16688
  umask: this.umaskOf(ppid),
16671
16689
  cred,
16672
16690
  tag: this.tagOf(ppid),
16691
+ ...group,
16673
16692
  ...exec
16674
16693
  });
16675
16694
  deciding?.attach();
@@ -16677,6 +16696,17 @@ var Launcher = class {
16677
16696
  return childHandle(handle);
16678
16697
  };
16679
16698
  }
16699
+ childGroup(ppid, req) {
16700
+ const { pgid, session } = req;
16701
+ if (pgid === void 0 && session === void 0) return {};
16702
+ const valid = pgid === void 0 || Number.isInteger(pgid) && pgid >= 0;
16703
+ if (req.exec || !valid || session !== void 0 && session !== true) return "EINVAL";
16704
+ if (session) return pgid === void 0 ? { group: "session" } : "EINVAL";
16705
+ if (pgid === 0) return { group: "lead" };
16706
+ const sid = this.jobs.sessionOf(pgid);
16707
+ if (sid === void 0) return "ESRCH";
16708
+ return sid === this.jobs.sidOf(ppid) ? { pgid } : "EPERM";
16709
+ }
16680
16710
  undecided(ppid) {
16681
16711
  const decided = Promise.withResolvers();
16682
16712
  return {
@@ -16707,7 +16737,7 @@ var Launcher = class {
16707
16737
  }, 0);
16708
16738
  }
16709
16739
  forker(ppid, parent) {
16710
- const { exec: _exec, ...image } = parent;
16740
+ const { exec: _exec, pgid: _pgid, group: _group, ...image } = parent;
16711
16741
  return async (state, fds) => childHandle(
16712
16742
  this.start({
16713
16743
  ...image,