> On Mar 21, 2017, at 6:27 AM, Elijah Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > I still like the idea of shared memory, but since without additional > threading it can’t have write access inside the new process, I don’t think > that it is a solution for a webserver. > > The main concern was just with developers using these universal exceptions > deliberately, along with “inconsistent states” and memory leaks. > > So here’s a simple proposal: > > func unsafeCatchFatalErrorWithMemoryLeak(_ block: ()->Void) -> FatalError? > > What it does is execute the block, and when the fatalError function is > invoked (as is the case with logic errors), the fatalError checks some thread > local for the existence of this handler and performs a goto. > “unsafeCatchFatalErrorWithMemoryLeak” then returns a small object with the > error message. The can only be one per-call stack, and it leaks deliberately > leaks the entire stack from “fatalError” back down to > “unsafeCatchFatalErrorWithMemoryLeak”, and that is one reason why it is > labelled “unsafe” and “withMemoryLeak”. > > The idea is that this is a function expressly for “high availability” > applications like web servers. The server will now have some leaked objects > posing no immediate danger, and some inconsistencies, primarily or entirely > inside the leaked objects (It is the developer’s responsibility how this is > used). > > The “high availability sytem” is then expected to stop accepting incoming > socket connections, generate another instance of itself, handle any open > connections, and exit. > > The interesting thing about this is that it is very easy to implement. Being > an unsafe function, it is not part of the language as a catch block is, and > doesn’t entirely preclude another solution in the future.
How much of the process can keep running after the fatal error is caught? A thread might still be too coarse-grained for a system based on workqueues. This also isn't particularly safe with objects accessed concurrently across multiple threads. If you have a method that temporarily breaks invariants on its instance, but crashes before it has a chance to reset them, then the object will still be in an inconsistent state when accessed later from surviving threads. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
