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 (ejrx7...@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 (br...@architechies.com) wrote: > On Mar 13, 2017, at 5:54 PM, Matthew Johnson <matt...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution