<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">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</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"> </span><span style="font-variant-ligatures:no-common-ligatures;color:#ba2da2">func</span><span style="font-variant-ligatures:no-common-ligatures"> openSharedObject(pid:</span><span style="font-variant-ligatures:no-common-ligatures;color:#703daa">String</span><span style="font-variant-ligatures:no-common-ligatures">) </span><span style="font-variant-ligatures:no-common-ligatures;color:#ba2da2">throws</span><span style="font-variant-ligatures:no-common-ligatures"> -> </span><span style="font-variant-ligatures:no-common-ligatures;color:#ba2da2">Any</span><span style="font-variant-ligatures:no-common-ligatures">? </span><span style="font-variant-ligatures:no-common-ligatures;color:#008400">// cast to expected value</span></p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures;color:#008400"><br></span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"> </span><span style="font-variant-ligatures:no-common-ligatures;color:#ba2da2">func</span><span style="font-variant-ligatures:no-common-ligatures"> registerSharedProxyObject(object:</span><span style="font-variant-ligatures:no-common-ligatures;color:#ba2da2">Any</span><span style="font-variant-ligatures:no-common-ligatures">) </span><span style="font-variant-ligatures:no-common-ligatures;color:#008400">// for this process</span></p></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I suppose the caller would have to be the one to compile these proxy objects and locate them in its own module.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Then one just needs, ideally, to get a stack trace and fatal error message to the parent process if a child process crashes.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div id="bloop_sign_1489530668879994880" class="bloop_sign"></div> <br><p class="airmail_on">On March 14, 2017 at 12:18:37 AM, Brent Royal-Gordon (<a href="mailto:brent@architechies.com">brent@architechies.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>> On Mar 13, 2017, at 5:54 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:
<br>
<br>>
<br>> 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.
<br>
<br>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.
<br>
<br>--
<br>Brent Royal-Gordon
<br>Sent from my iPhone</div></div></span></blockquote></body></html>