[swift-evolution] Swift null safety questions

[Elijah Johnson]

But - that would require a dedicated thread or a thread pool to run
function calls on. Definitely it lacks many of the advantages of shared
objects directly in the process. I would definitely prefer a small memory
leak or inconsistent state. The server could handle existing requests and
restart itself if it were really an issue. A memory leak can be estimated
and the server restarted after every “x” times, while an inconsistent state
is something that happens in any shared server environment. The developers
just don’t modify the shared state until they have ready the final object,
and their array/dictionary put function call itself isn’t likely to be the
fail that happened.


On March 14, 2017 at 7:29:28 PM, Elijah Johnson (ejrx7753 at gmail.com) wrote:

Also the proxies would need to implement some protocol so that they can be
de-proxied when sent back to a shared method, and the proxy object exposed
to the user with a new declaration that accepts only proxies. Like using
MyClass -> MyClassSharedProxy for the proxy class and

class MyClass {

    func testReturnsObject() -> SomeClass
    func call(a:MyClass) -> MyClass

}

would become

class MyClassSharedProxy : MyClass, SharedProxyProtocol {

    func testReturnsObject() -> SomeClassSharedProxy
    func call(a:MyClassSharedProxy) -> MyClassSharedProxy

}


for example.


On March 14, 2017 at 7:15:08 PM, Elijah Johnson (ejrx7753 at gmail.com) wrote:

Sounds like a good idea. I assume that Swift would need to compile these
proxies in advance to be sub-classes ie. binary compatible objects that
will forward calls and return proxies. “Value” types can be copied as they
normally are, or wrapped by the user (along with “final” objects which
could be wrapped manually or made not-final). Then you’d just need a way to
get your first proxy object and a way to register the process’s object.
Something like

    func openSharedObject(pid:String) throws -> Any? // cast to expected
value


    func registerSharedProxyObject(object:Any) // for this process

I suppose the caller would have to be the one to compile these proxy
objects and locate them in its own module.

The advantage here is that it would be not too difficult for existing
servers to make use of this, as they are already written as a single
process in Swift and so they would just need to manage and pre-fork
processes instead of threads. Seems like it would also have numerous uses
in the systems programming domain.

Then one just needs, ideally, to get a stack trace and fatal error message
to the parent process if a child process crashes.




On March 14, 2017 at 12:18:37 AM, Brent Royal-Gordon (brent at architechies.com)
wrote:

> On Mar 13, 2017, at 5:54 PM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> I suspect you're right about this for the most part but I think we will
want the ability for "failable processes" (or whatever they're called) to
have read-only access to shared state that outlives them. What I can't
imagine is allowing them write access to state that is shared.

The problem there is that shared data in Swift always has a retain count,
so we'd need some way to track when code in one of these "mini-processes"
retains an external object so we can release it if it crashes. Perhaps
you'd need to wrap a proxy type around shared objects (or instances
containing shared objects, like Array and String) and the proxies would
register themselves with the runtime as needing emergency cleanup beyond
unceremonious deallocation of their "mini-process"'s memory space. This is
all doable; it just needs to be designed and done.

--
Brent Royal-Gordon
Sent from my iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170314/2bcaf5af/attachment.html>