GitLab

Update EnsureCanonicalObject so that it can optionally skip reading the file/object length, based on the new argument R7. Then trace back through the callers to have them pass in an appropriate value based on whether they care about the length or not.

TopPath_DoBusinessToPath has also gained a new flag bit to suppress reading the length, but so far I've only updated DoThePath to use it.

Result: If you have a file in PipeFS which is open for writing, and then attempt to open it for reading using OS_Find, it'll now open immediately instead of PipeFS trying to block/sleep until it's no longer open for writing.

Why: Since at least as far back as RISC OS 3.6, PipeFS tries to sleep inside fsfile_ReadInfo if the file is open for writing. But a combination of buggy sleep logic and TaskWindow's lazy approach to UpCall 6 meant that (prior to TaskWindow 0.65) it wouldn't sleep for long and would instead allow the open to proceed while the file is still open for write. The ability to have both a reader & writer active at the same time is basically the whole point of PipeFS, so this change restores that pre-TaskWindow 0.65 behaviour without having to remove the sleep logic from PipeFS (it's a well-intentioned feature, even though it's been broken for decades)

Also now that OS_TaskControl is in the kernel, merge in my change to make FileSwitch use it when starting a program.

Tested by performing a ROM build, checking that it works, and running some PipeFS tests.

This fixes the original issue described in ticket 480: https://www.riscosopen.org/tracker/tickets/480