On a Posix-compatible filesystem, an open file remains intact after it is unlinked, but this is not true on Windows, where the deletion will fail. In general attempts to backtrack over external (non memory) side effects like reads, writes, and seeks are ineffective.
On Sun, Dec 15, 2024, 4:50 PM Wolfgang Corcoran-Mathe <[email protected]> wrote: > On 2024-12-15 22:08 +0100, Marc Nieper-Wißkirchen wrote: > > There should be an > > option to abort a restarter, meaning to reraise the original condition > > to handle it further up in the handler stack. > > That makes sense to me. Should 're-raise' be a recommended restarter > tag? > > > The current model has the problem that handlers further up the handler > > stack cannot know whether the condition they observed will eventually > > have been handled or not. > > I'm not sure I know exactly what you mean, but this reminds me of > the fundamental problem with SRFI 249's restarters, which didn't > capture control context. SRFI 255's restarters do, but there is more > context (like the complete handler stack and filesystem state) that > they can't capture. If you are reading from a file and an up-stack > handler deletes the file, then a 'retry' restarter added by the > reading procedure will crash. > > I don't currently know how to solve this problem. > > > Apart from that, a restarter is added by a handler; in your example, > > the restarter would have only been added in case of an io-read-error?. > > How's that? It's true that the restarter would only be added to an I/O > read condition, but this is because I've specified 'restarter-guard' > to check the triggering condition against each restarter's condition > predicate. Without those predicates, you would get all of the restarters > installed with restarter-guard, regardless of the condition type. > > I agree that condition predicates are a bit coarse, but a more general > mechanism for determining whether a given restarter is relevant would > need much more context (see above). > > Regards, > > Wolf >
