{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/39","repository_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem","labels_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/39/labels{/name}","comments_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/39/comments","events_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/39/events","html_url":"https://github.com/tc39/ecmascript_sharedmem/issues/39","id":122692257,"number":39,"title":"Formalize embedding-specific constraints on worker types and reaction to illegal sharing","user":{"login":"lars-t-hansen","id":4823190,"avatar_url":"https://avatars.githubusercontent.com/u/4823190?v=3","gravatar_id":"","url":"https://api.github.com/users/lars-t-hansen","html_url":"https://github.com/lars-t-hansen","followers_url":"https://api.github.com/users/lars-t-hansen/followers","following_url":"https://api.github.com/users/lars-t-hansen/following{/other_user}","gists_url":"https://api.github.com/users/lars-t-hansen/gists{/gist_id}","starred_url":"https://api.github.com/users/lars-t-hansen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lars-t-hansen/subscriptions","organizations_url":"https://api.github.com/users/lars-t-hansen/orgs","repos_url":"https://api.github.com/users/lars-t-hansen/repos","events_url":"https://api.github.com/users/lars-t-hansen/events{/privacy}","received_events_url":"https://api.github.com/users/lars-t-hansen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":11,"created_at":"2015-12-17T09:12:06Z","updated_at":"2016-03-03T10:23:31Z","closed_at":null,"body":"In Firefox we'll likely have to prevent SharedWorkers and ServiceWorkers from sending or receiving shared memory, since we anticipate that that will cause complications when paired with process separation.  (See https://bugzil.la/1232973 .)\r\n\r\nThe shared memory spec already hints at this in section 8.1, but it may be beneficial for interop to give this restriction teeth, somehow, eg, by providing information about what should happen when trying to send a SharedArrayBuffer in an illegal way.  Clearly this is more in the purview of WHATWG/W3C than ECMA, but even so.  The information would go in what is now section 8.5.\r\n\r\n(EDIT: Corrected the bugzilla link.)\r\n"},"comment":{"url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/comments/191695451","html_url":"https://github.com/tc39/ecmascript_sharedmem/issues/39#issuecomment-191695451","issue_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/39","id":191695451,"user":{"login":"lars-t-hansen","id":4823190,"avatar_url":"https://avatars.githubusercontent.com/u/4823190?v=3","gravatar_id":"","url":"https://api.github.com/users/lars-t-hansen","html_url":"https://github.com/lars-t-hansen","followers_url":"https://api.github.com/users/lars-t-hansen/followers","following_url":"https://api.github.com/users/lars-t-hansen/following{/other_user}","gists_url":"https://api.github.com/users/lars-t-hansen/gists{/gist_id}","starred_url":"https://api.github.com/users/lars-t-hansen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lars-t-hansen/subscriptions","organizations_url":"https://api.github.com/users/lars-t-hansen/orgs","repos_url":"https://api.github.com/users/lars-t-hansen/repos","events_url":"https://api.github.com/users/lars-t-hansen/events{/privacy}","received_events_url":"https://api.github.com/users/lars-t-hansen/received_events","type":"User","site_admin":false},"created_at":"2016-03-03T10:23:31Z","updated_at":"2016-03-03T10:23:31Z","body":"OK, thanks.  It's probably inevitable that we don't want to share memory among certain pairs of agents that can communicate by postMessage, but there are actually two ways to accomplish that.  One is to restrict the structured clone mechanism.  The other is to realize that the shared memory can only be accessed in the receiving agent if the agent can create a TypedArray on top of the SharedArrayBuffer that it receives, and therefore to allow SharedArrayBuffers to be tagged in such a way that that creation fails.  (The distinction may not matter to the implemenation, I'm thinking only about spec work.)  The tagging will have something to do with \"compatible\" agent clusters, maybe.  We might need that in order to spec what this bug is really about anyway.\r\n\r\nWhether that is uglier to spec than just speccing restrictions on structured clone I don't know.  It probably moves the problem from the structured clone spec to the ES spec.  The ES spec might say that \"if the buffer is a SAB and the SAB's tag is incompatible with the current agent's tag then treat the SAB as length 0 / throw an exception\".  I've seen worse."}}