# Detecting a closed channel?

**URL:** https://discourse.julialang.org/t/detecting-a-closed-channel/9289
**Category:** General Usage
**Created:** [February 23, 2018, 11:02pm UTC](https://discourse.julialang.org/t/detecting-a-closed-channel/9289 "2018-02-23T23:02:57Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![pasha](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pasha/32/3319_2.png) [@pasha](https://discourse.julialang.org/u/pasha)
#### Post date: [February 24, 2018, 2:20am UTC](https://discourse.julialang.org/t/detecting-a-closed-channel/9289/2 "2018-02-24T02:20:56Z")

</div>

I flailed around on a an approach resembling yours [in my MWE here](https://discourse.julialang.org/t/parallel-map-reduce-with-remotechannels-comments-on-mwe/8761) and hit the wall where there is no `isopen()` function nor an `open()` for `RemoteChannel`. In that MWE code above, I had to detect that the channel was closed by catching the error and exiting the loop. Crude, and there was no way to restart the thing because there is no `open()`

Later, I set up code to put zero-flagged jobs onto the job queue, and the workers would exit when they saw a zero job. There was a bit of flushing the pipes but it worked.

Then, I abandoned the whole approach and went to a variant of the scheduler [in the example code](https://docs.julialang.org/en/stable/manual/parallel-computing#Scheduling-1). This works better in my case, because `emit()` was causing too much data traffic, and it was better to accumulate map results in the worker before returning a result. I’m happy with this method.

So, the answer is that you have to catch the error, but there may be more elegant ways to do it.

---

_[View the full topic](https://discourse.julialang.org/t/detecting-a-closed-channel/9289)._