[swift-evolution] Swift null safety questions

[Joe Groff]

> On Mar 21, 2017, at 6:27 AM, Elijah Johnson via swift-evolution <swift-evolution at 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