Soil Object Database ported to VAST. Initial and untested
Dusty
Peter Ode
I've got this working, in VAST on windows. Will need to test on not-windows operating systems.Git repo: riverdusty/Soil-in-VAST
--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/26eae914-4247-45d9-b90e-2e54ce664607n%40googlegroups.com.
Dusty
Also, I've submitted a PR to soil to fix the locking on windows, you can check the soil repo on my github for that fix.
Dusty
I got claude to summarise this.
Short version: right now the port doesn't actually lock on Windows — it's stubbed for single-image use. But VAST's CFS gives us real Windows locking for free when we wire it in. Here's the full picture.
Current state (v1): stubbed, single-image onlyThe locking surface is in place but does nothing:
- SoilLockableStream has lockAppendingFor:, lockFrom:length:for:, lockFrom:to:for:, unlockFrom:to:for: — they create SoilRangeLock objects and track them in an in-image locks collection.
- SoilRangeLock's lockInMemory:, lockOn:, release are no-ops, and SoilLockableStream>>lockFromOsIfNeeded: is an empty hook.
So no OS-level lock is ever taken. This is safe for a single VAST image using a database, but not safe for multiple processes/images sharing one database on disk. That's deliberate — locking belongs with the deferred WAL-journal/concurrency layer, and v1 targets single-image use.
What VAST gives us for real Windows lockingVAST's Common File System already abstracts OS region locking, and the CfsFileDescriptor you shared me was the Windows implementation (Win32 GetFileSizeEx, OSUInt64, ERROR_INVALID_HANDLE), so Windows is fully supported. The API is:
fileDescriptor lock: type start: byteOffset len: byteCount. fileDescriptor unlock: type start: byteOffset len: byteCount.with three lock types (from CfsConstants):
FRDLOCK
shared (read) advisory — blocks others' exclusive locks
FWRLOCK
exclusive (write) advisory — blocks others' shared or exclusive
FMDLOCK
exclusive mandatory — blocks others' reads/writes/locks entirely
On Windows these map to the Win32 file-locking calls (LockFileEx/UnlockFileEx), and unlocking must use the exact type/start/len used to lock — which is why SoilLockableStream already saves each lock's range in a SoilRangeLock.
Why this is easier than upstreamPharo Soil couldn't do Windows until v5 and needed hand-rolled Win32 overlapped-I/O structs (SoilWinOverlappedStruct, SoilWindowsFileLock). The VAST port skips all of that — CFS already normalizes region locking across Windows/Unix/macOS, so we don't touch Win32 directly.
How we'd turn it onIt's a small, contained change to the two hooks:
SoilLockableStream >> lockFromOsIfNeeded: aRange self fileLocked ifTrue: [ fileDescriptor lock: FWRLOCK start: aRange from len: aRange length ] SoilLockableStream >> unlockFrom: from to: to for: ctx ... fileDescriptor unlock: FWRLOCK start: from len: to - from ...Soil locks specific byte ranges rather than whole files — the last-object-index slot (during id allocation), the append region (from: 0 to: 0), and per-object index slots (for optimistic-concurrency conflict detection). CFS supports all of those directly.
Bottom line: locking is designed-in but intentionally inert for v1; enabling real multi-process Windows locking is a localized wiring job against CfsFileDescriptor>>lock:start:len:, with no Win32 code of our own. Want me to implement it now, or keep it with the concurrency/journal batch?