Make isempty(c::Channel) a non-mutating operation

[staticfloat]

Previously, isempty(c::Channel) would fall back to iterate(c) === nothing, which actually consumed a value from the channel. Instead,
let's just define it in terms of isready(c) since that already exists.

[StefanKarpinski]

Seems like arguably a bugfix. I would not think that isempty should consume anything in general.

[vtjnash]

I wonder if we should also define this in terms of isempty on the internal objects (O(1)) instead of length (O(n)), but this is a good fix regardless

[staticfloat]

I'm honestly not sure when this fallback is a good idea:

julia/base/essentials.jl

Line 773 in 110765a

iterate(itr) === nothing

It seems a bad idea to me to ever call iterate(itr) to check if it's empty.

[Keno]

I'm honestly not sure when this fallback is a good idea:

We have very few iterators that are mutable, but they have a few extra requirements. We should probably document what those are ... or at least figure out what they are ;).

[Keno]

That said, there is a bit of a problem with this kind of query in general, since isempty being true here doesn't mean that you can't get an object from it, it just means that it'll block. Obviously this definition is strictly better than the fallback we had before (since that answer would be both useless and maybe drop an object you care about), but I'm wondering if we should have it at all.

[staticfloat]

since isempty being true here doesn't mean that you can't get an object from it, it just means that it'll block

I think that's the difference between isempty() and !isopen(); just because something is empty doesn't mean it's permanently empty.

[JeffBezanson]

I am quite sure we did not intend isempty to be used on Channels, since it doesn't really make sense to have both that and isready. I also wish isready did not exist, since it's just a race condition. So I'm curious, how did this come up?

[staticfloat]

how did this come up?

The usual method of applying verbs from other areas and seeing if they work; I had a Channel that I closed and wanted to drain, so I wrote:

close(c)
while !isempty(c)
    process(take!(c))
end

Which seemed to work, except then I noticed it was only processing every other item. I would be fine with defining isempty() more narrowly and telling everyone to use isready(). I agree that there's something of a mixture of concerns here; what my use case really wants is for eof(::Channel) to be defined, which would be something like !isopen(c) && !isready(c). That way we aren't relying upon the caller to have already closed the channel to avoid raciness.

[JeffBezanson]

I think the only thing that really works for that is something like iterate, where you either get a value or find out there aren't any more.

[codecov-commenter]

Codecov Report

Merging #36641 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #36641   +/-   ##
=======================================
  Coverage   86.15%   86.15%           
=======================================
  Files         349      349           
  Lines       65809    65809           
=======================================
  Hits        56698    56698           
  Misses       9111     9111           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 110765a...5ad48c7. Read the comment docs.