Fork me on GitHub
#core-async
<
2017-06-08
>
danboykis12:06:21

anyone have suggestions for what to do when you have to call blocking IO within a go block? So far my idea is to submit the blocking task to a thread pool but I am not sure how to handle the situation if the theadpool gets overwhelmed and have to deal with RejectedExecutionException(s)

jsa-aerial13:06:52

The correct answer to that is "Don't do that"...

danboykis13:06:46

i don't think that's the correct answer, unless core.async is significantly less practical than I thought, other similar tools allow blocking io workarounds, for example vertx

tbaldridge13:06:51

What you suggested isn't a bad idea, create a pool to do the blocking IO, then communicate with the pool using channels

tbaldridge13:06:38

and if you want to do blocking io in a go-like context you can spin up a new Java thread via core.async/thread

tbaldridge13:06:02

that approach is what Vert.X is doing, they're spinning up a new thread and running the blocking code in that thread

danboykis13:06:56

@tbaldridge thanks, any tips on doing error handling in that scenario?

tbaldridge13:06:08

What you're looking at here is a Call/Response setup, in general I try to avoid this sort of thing

tbaldridge13:06:00

instead I try to structure my core.async code as a pipeline, perhaps with async/pipeline,

tbaldridge13:06:22

in this case you would flow values into the pipeline and you'd get out {:value ...} {:error "...."}

danboykis14:06:58

i've give pipeline a look, ty