{"action":"opened","issue":{"url":"https://api.github.com/repos/scalaz/scalaz-stream/issues/447","labels_url":"https://api.github.com/repos/scalaz/scalaz-stream/issues/447/labels{/name}","comments_url":"https://api.github.com/repos/scalaz/scalaz-stream/issues/447/comments","events_url":"https://api.github.com/repos/scalaz/scalaz-stream/issues/447/events","html_url":"https://github.com/scalaz/scalaz-stream/issues/447","id":111879363,"number":447,"title":"Task non-atomicity of interruption considered harmful","user":{"login":"djspiewak","id":752,"avatar_url":"https://avatars.githubusercontent.com/u/752?v=3","gravatar_id":"","url":"https://api.github.com/users/djspiewak","html_url":"https://github.com/djspiewak","followers_url":"https://api.github.com/users/djspiewak/followers","following_url":"https://api.github.com/users/djspiewak/following{/other_user}","gists_url":"https://api.github.com/users/djspiewak/gists{/gist_id}","starred_url":"https://api.github.com/users/djspiewak/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/djspiewak/subscriptions","organizations_url":"https://api.github.com/users/djspiewak/orgs","repos_url":"https://api.github.com/users/djspiewak/repos","events_url":"https://api.github.com/users/djspiewak/events{/privacy}","received_events_url":"https://api.github.com/users/djspiewak/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-10-16T17:52:34Z","updated_at":"2015-10-16T17:52:34Z","closed_at":null,"body":"This is something that we already decided to do away with in fs2 for simplicity and design reasons, but I think it's actually actively problematic even in the existing design.  Think about any sort of network IO or coordination problem, expressed as a series of composed `Task`(s), and then `eval`ed into scalaz-stream.  The coordination sequentialization and guarantees that you would expect *will not hold* simply because it's running within the `stepAsync` interpreter, meaning that the `Task` in question can be interrupted at any `bind` point without recourse or signal.\r\n\r\nAs it turns out, that's mildly inconvenient…  By show of hands, if I removed the `Task` cancelation semantics from 0.8 (in an 0.8.1 release, probably) such that any `Task` you `eval` (or equivalently, `await`) is guaranteed to either run fully to completion or *never* run at all, would anyone have any problems?  It would mean that you would need to be careful not to construct infinitely-processing tasks (e.g. `Process eval p1.repeat.runLog` for some non-empty process `p1` would be a no-no), but I think that, in general, infinities are idiomatically pushed into `Process` simply because they're easier to handle and schedule there.  So this shouldn't break anyone's *well constructed* code, and it should make some things (especially anything dealing with IO) much more reliable in the face of asynchronous interrupts and errors."}}