@ai-ecoverse/slicc-kernel 1.124.9 → 1.124.11
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 +5 -0
- package/dist/kernel-worker.js +1 -1
- package/dist/kernel-worker.js.map +2 -2
- package/dist/node-process-worker.js +70 -12
- package/dist/node-process-worker.js.map +2 -2
- package/dist/node.js +1 -1
- package/dist/node.js.map +2 -2
- package/dist/process-worker.js +70 -12
- package/dist/process-worker.js.map +2 -2
- package/dist/types/realm/sync-fs-wire.d.ts +1 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -986,6 +986,11 @@ A kernel caches the directory handles it has walked and the sidecar entries it h
|
|
|
986
986
|
|
|
987
987
|
So a locked read-modify-write across tabs (sqlite, a JSON counter under `flock`) is exact, and anything else between tabs is as fresh as the last notice. Programs add their own rule on top: see "Another tab's writes" above. `crowded-lookups.test.mjs` and `notice-caches.test.mjs` hold the rows. The `notice-caches` rows freeze one kernel's clock and drop the other's notices, through the kernel workers in `test/integration/page/notice/`.
|
|
988
988
|
|
|
989
|
+
**Within one kernel** ([#1026](https://github.com/ai-ecoverse/slicc-kernel/issues/1026)): a WASI process keeps the stats it has read, and checks each one against the kernel's change ring at every look. So a process that keeps stat-ing a file, even in a loop that never sleeps, sees another process's change to that path at its next stat. Before #1026's fix, from v1.4.0 on, a stat it had looked up lasted until the process slept, polled, waited for a child or wrote the path itself. The ring names the changed paths only, so in a loop with none of those calls, a stat stays stale until the next sleep, poll, wait or own write when the change was named elsewhere:
|
|
990
|
+
- a write through another hard link of the same file. Only tmpfs mounts support `link`; on the OPFS root and every other mount, a file's link count is always 1;
|
|
991
|
+
- a change to a symlink's target (the notice names the target, not the link);
|
|
992
|
+
- an ancestor renamed or replaced (`mv /a /c; mv /d /a`: the notices name `/a`, `/c` and `/d`, not `/a/f`).
|
|
993
|
+
|
|
989
994
|
The filesystem is our own rather than [ZenFS](https://github.com/zen-fs/core) (which SLICC uses), because OPFS stays the single source of truth: other writers, such as the BIOS installing packages or a page writing files, need no index to stay consistent with, and nothing is preloaded into memory at mount. POSIX metadata lives in the IndexedDB sidecar described above, which has per-entry transactions instead of one JSON file rewritten on every change.
|
|
990
995
|
|
|
991
996
|
## What is in here
|
package/dist/kernel-worker.js
CHANGED
|
@@ -6625,7 +6625,7 @@ function satisfies(version, range2) {
|
|
|
6625
6625
|
}
|
|
6626
6626
|
|
|
6627
6627
|
// src/version.ts
|
|
6628
|
-
var KERNEL_VERSION = true ? "1.124.
|
|
6628
|
+
var KERNEL_VERSION = true ? "1.124.11" : "0.0.0-dev";
|
|
6629
6629
|
var OS_RELEASE = "6.0.0-slicc";
|
|
6630
6630
|
function procVersion() {
|
|
6631
6631
|
return `Linux version ${OS_RELEASE} (slicc-kernel ${KERNEL_VERSION}) #1 SMP PREEMPT_DYNAMIC
|