Skip to content

Conversation

@mpilquist
Copy link
Member

@mpilquist mpilquist commented Sep 8, 2019

Stream.bracketCancellable and Stream.bracketCaseCancellable allowed early, manual finalization of resources. Upon invoking the finalizer, the internal resource would be cleaned up, ensuring we don't leak references to already invoked finalizers. Now that we introduce a scope for each bracket, folks would expect that invoking cancelation of this case also closes the dedicated scope -- i.e., we don't leak scopes either. Instead of implementing this, I'd like to remove these operations instead. There were no tests for these operations and they were very rarely used. Searching GitHub shows no GH hosted open source projects use either operation.

Similarly, Pull.acquireCancellable provided a mechanism to manually invoke finalizers. I added this back in #662 to fix resource leaks, but the motivating use cases at the time are all addressed now by using effect level bracketing.

Removal of Pull.acquire is perhaps the most controversial. When Pull was the primary mechanism in which scopes were created, acquiring a resource via Pull made more sense than it does now.

This PR also introduces a s.pull.headOrError method, that converts a Stream[F, O] to a Pull[F, INothing, O]. Uses of Pull.acquire can be replaced with Stream.bracket(acquire)(release).pull.headOrError.

Note: the only place where Pull.Cancellable was used was in the constructors for FileHandle in fs2.io.file.pulls. These were vestiges of a time before cats.effect.Resource. These constructors were removed in favor of new constructors on FileHandle companion that return Resource[F, FileHandle[F]].

@mpilquist mpilquist requested a review from SystemFw September 9, 2019 14:09
@mpilquist mpilquist added this to the 1.1.0 milestone Sep 9, 2019
Copy link
Collaborator

@SystemFw SystemFw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm satisfied by the argument behind this PR, and the removal of several complex bits is quite nice. Left one minor comment on Pull.singleton

* Takes the first value output by this stream and returns it in the result of a pull.
* If no value is output before the stream terminates, the pull is failed with a `NoSuchElementException`.
* If more than 1 value is output, everything beyond the first is ignored.
*/
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if there is any particular reason for the inconsistency with compile.lastOrError

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the inconsistency, just the name? I'll rename to headOrError.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just the last vs first behaviour. I can see how Pull is more first-y (uncons), but it's inconsistent with lastOrError. Not a big deal though

@mpilquist mpilquist merged commit 159d881 into typelevel:series/1.1 Sep 10, 2019
@mpilquist mpilquist deleted the topic/remove-explicit-resource-cancelation branch February 18, 2020 12:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants