{"action":"created","issue":{"url":"https://api.github.com/repos/phoenixframework/phoenix/issues/648","labels_url":"https://api.github.com/repos/phoenixframework/phoenix/issues/648/labels{/name}","comments_url":"https://api.github.com/repos/phoenixframework/phoenix/issues/648/comments","events_url":"https://api.github.com/repos/phoenixframework/phoenix/issues/648/events","html_url":"https://github.com/phoenixframework/phoenix/pull/648","id":59557961,"number":648,"title":"Adds support for processes per Phoenix.Socket","user":{"login":"ephe-meral","id":1501017,"avatar_url":"https://avatars.githubusercontent.com/u/1501017?v=3","gravatar_id":"","url":"https://api.github.com/users/ephe-meral","html_url":"https://github.com/ephe-meral","followers_url":"https://api.github.com/users/ephe-meral/followers","following_url":"https://api.github.com/users/ephe-meral/following{/other_user}","gists_url":"https://api.github.com/users/ephe-meral/gists{/gist_id}","starred_url":"https://api.github.com/users/ephe-meral/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ephe-meral/subscriptions","organizations_url":"https://api.github.com/users/ephe-meral/orgs","repos_url":"https://api.github.com/users/ephe-meral/repos","events_url":"https://api.github.com/users/ephe-meral/events{/privacy}","received_events_url":"https://api.github.com/users/ephe-meral/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-03-02T21:56:40Z","updated_at":"2015-03-03T12:16:39Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/phoenixframework/phoenix/pulls/648","html_url":"https://github.com/phoenixframework/phoenix/pull/648","diff_url":"https://github.com/phoenixframework/phoenix/pull/648.diff","patch_url":"https://github.com/phoenixframework/phoenix/pull/648.patch"},"body":"RFC\r\n\r\nMain goal of these changes was to implement `handle_info` for channels, so that the user can send arbitrary messages to its own socket-process (e.g. from within the channel) and handle them there.\r\n\r\nMight break backwards compatibility with code that relies on the inner workings of Transport. "},"comment":{"url":"https://api.github.com/repos/phoenixframework/phoenix/issues/comments/76934975","html_url":"https://github.com/phoenixframework/phoenix/pull/648#issuecomment-76934975","issue_url":"https://api.github.com/repos/phoenixframework/phoenix/issues/648","id":76934975,"user":{"login":"ericmj","id":316890,"avatar_url":"https://avatars.githubusercontent.com/u/316890?v=3","gravatar_id":"","url":"https://api.github.com/users/ericmj","html_url":"https://github.com/ericmj","followers_url":"https://api.github.com/users/ericmj/followers","following_url":"https://api.github.com/users/ericmj/following{/other_user}","gists_url":"https://api.github.com/users/ericmj/gists{/gist_id}","starred_url":"https://api.github.com/users/ericmj/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ericmj/subscriptions","organizations_url":"https://api.github.com/users/ericmj/orgs","repos_url":"https://api.github.com/users/ericmj/repos","events_url":"https://api.github.com/users/ericmj/events{/privacy}","received_events_url":"https://api.github.com/users/ericmj/received_events","type":"User","site_admin":false},"created_at":"2015-03-03T12:16:38Z","updated_at":"2015-03-03T12:16:38Z","body":"@josevalim makes a good point. Multiplexed channels on a single connection are for all intents and purposes separated but they are not separate in failure semantics. A crash in one channel will crash all the multiplexed channels.\r\n\r\n> So there's my brain dump on this. My current feelings are handle_info and generic messages are an edge-case for channels and we should promote broadcasts instead (given flaky connections and replays). So if handle_info is an edge case, and we already have workaround today with broadcast/handle_out, is this needed? Are the tradeoffs worth it?\r\n\r\nThese are not edge cases, trapping exits and monitors is standard functionality that you will very likely use in all your applications. And it's not just that, 100% of all existing libraries have been built for vanilla  message passing so if I want to use a library not built with phoenix in mind I need to wrap my calls in a new process and handle all receives by doing broadcasts back to my channel."}}