[swift-users] Bls: Bls: module (de)-initialization

[Joe Groff]

> On Dec 21, 2016, at 7:29 PM, Mr Bee <pak.lebah at yahoo.com> wrote:
> 
> Sorry for not being clear. My english isn't very good either.
> 
> What I meant was static module linking (loading and unloading) for Swift modules. Also with initialization and deinitialization for Swift modules.
> 
> It's alright then. I just want to make sure. I'm a Pascal/Delphi programmer and sometimes I rely on such features in my applications. As a new and considered as modern programming language, I thought Swift would provide more advance features than Pascal/Delphi does.

I'd be interested to hear what you need these features for. Delphi was a direct descendent of Turbo Pascal, which came from a platform with extreme memory constraints and a not-very-sophisticated memory, so loading and unloading modules to save memory may have made sense. On a modern platform with virtual memory, loading an executable image does not take up much actual memory, since the majority of pages in most executables are read-only and can be memory-mapped in and out from disk on demand. Even if you unload a module, the dynamic linker should not reuse the address space that module was mapped into when loading other modules for security reasons (an attacker could turn a dangling function pointer in the host process into a JOP vector by remapping new code there). Also for security reasons, a modern application ought to favor an out-of-process extension model to dynamically loading code in-process; there are no problems cleanly spawning and killing a plug-in process.

As for load-time initialization, that is well-known to be a problematic feature in languages that support it, and it is not the only nor the best approach to solving the problems it's applied to—see https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161114/028914.html for a discussion of the problems with load-time initializers and alternative features that solve the same problems in a more robust way. Exit-time deinitialization is also problematic, since there's no way in practice to guarantee that cleanups happen before a process dies, so code that relies on them is fundamentally brittle and prone to corrupting user data. It's also at odds with the modern macOS and iOS process model, which expects to be able to terminate UI processes at any point.

-Joe