# Core.async and crashing the repl

**URL:** https://clojureverse.org/t/core-async-and-crashing-the-repl/5221
**Category:** Troubleshooting
**Created:** [December 16, 2019, 7:36pm UTC](https://clojureverse.org/t/core-async-and-crashing-the-repl/5221 "2019-12-16T19:36:45Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![andersmurphy](https://clojureverse.org/user_avatar/clojureverse.org/andersmurphy/32/1960_2.png) [@andersmurphy](https://clojureverse.org/u/andersmurphy)
#### Post date: [December 16, 2019, 7:36pm UTC](https://clojureverse.org/t/core-async-and-crashing-the-repl/5221/1 "2019-12-16T19:36:45Z")

</div>

I’ve started playing around with core.async recently and I noticed that if there is crash in an async process it seems to crash the repl. Is there anything that can be done to avoid this? Restarting the repl messes with my workflow. 😅

Any tips would be greatly appreciated. 😃

---

<div class="post-metadata">

### Author: ![teodorlu](https://clojureverse.org/user_avatar/clojureverse.org/teodorlu/32/2896_2.png) [@teodorlu](https://clojureverse.org/u/teodorlu)
#### Post date: [December 17, 2019, 9:14am UTC](https://clojureverse.org/t/core-async-and-crashing-the-repl/5221/2 "2019-12-17T09:14:51Z")

</div>

Hello, @andersmurphy!

I feel your pain. I’ve been near there. Trying to learn core.async, and repeatedly having to restart my REPL because I launched a background process I couldn’t stop, or did something else I didn’t intend.

My conclusion:

- Accept that restarting the REPL a lot in the beginning might be necessary
- Consider using a system such as Integrant to start and stop background processes

A bit further out there:

- Consider wrapping some core.async to ensure that channels can be stopped. Register all channels to a global atom, and provide a `stop-everything!` or similar.

I don’t really consider this solutions, though, just where I’d go if I wanted to push the issue a bit further.

Teodor

---

<div class="post-metadata">

### Author: ![joinr](https://clojureverse.org/user_avatar/clojureverse.org/joinr/32/1861_2.png) [@joinr](https://clojureverse.org/u/joinr)
#### Post date: [December 17, 2019, 9:43am UTC](https://clojureverse.org/t/core-async-and-crashing-the-repl/5221/3 "2019-12-17T09:43:51Z")

</div>

Same problem when I first started messing with it. It’s very easy to get the threadpool locked up…  
By default, there’s nothing really keeping track of the lifetime of any go-loops or threads. It’s very easy to spawn off infinite processes. So…always ensure there’s some lifetime management, such as an atom, timeouts, or a poison pill channel.

I rigged up a [system](https://github.com/joinr/spork/blob/master/src/spork/async/system.clj) infrastructure to help manage this kind of stuff when I was experimenting. There’s an [example here](https://gist.github.com/joinr/b6144113321c9582120cc3a1d9293f3c) of using it. The basic premise is having a process abstraction to keep a handle for communicating with the async stuff, and providing means to start/stop/kill, etc. So really just any way to provide visibility on the stuff you’re spooling up. I actually found it to be quite a useful exercise to build something like this since it helped me learn more about core.async in the process.

Another one is the default (chan) will have a 1 for 1 channel. I found that - when experimenting early on - using something more forgiving like dropping channels were helpful to at least keep things “moving” when I screwed up.

I think there are some better libraries for process management (even an erlang OTP actor-like one with supervisors). That gets you a bit away from learning core.async, but they could be useful down the road.

---

<div class="post-metadata">

### Author: ![system](https://clojureverse.org/uploads/default/original/2X/5/51079bf9e4b7d9466242c06cf1e43b9f8bd6da14.png) [@system](https://clojureverse.org/u/system)
#### Post date: [June 16, 2020, 9:43pm UTC](https://clojureverse.org/t/core-async-and-crashing-the-repl/5221/4 "2020-06-16T21:43:51Z")

</div>

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.
