Special behavior built into only certain blocking operations (e.g.,
core.async's, but not java.io's) could instill a false sense of security.
It could be complemented by a watchdog thread to poll the core.async pool
threads and call a given fn if a thread was blocked when it shouldn't have
>
> No code called by a go block should ever call the blocking variants of
> core.async functions (!!, alts!!, etc.). So I'd start at the code
> redacted in those lines and go from there.
>
Seems like a good use case for a static code analyser. Maybe a
contribution to
We did actually discuss doing something like this a long time ago. The
worry that comes to mind is whether it should actually be forbidden (an
invariant) or merely strong frowned upon. It is possible to arrange a
situation where you know (based on other knowledge) that a put on a channel
will
Ahh that makes a lot of sense. Indeed, I'm guilty of doing a blocking >!!
inside a go-block. I was so careful to avoid other kinds of blocking calls
(like IO) that I forgot that blocking variants of core.async calls
themselves were forbidden.
Thank you for pointing this out! I will rewire
Hm, I came across a similar ordering invariant (No code called by a go
block should ever call the blocking variants of core.async functions) while
wrapping an imperative API, and I thought it might be useful to use
vars/binding to enforce it. Has this or other approaches been considered
in
To add to what Alex said, look at this trace:
https://gist.github.com/anonymous/65049ffdd37d43df8f23630928e8fed0#file-thread-dump-out-L1337-L1372
Here we see a go block calling mapcat, and inside the inner map something
is calling >!!. As Alex mentioned this can be a source of deadlocks. No
code
go blocks are multiplexed over a thread pool which has (by default) 8
threads. You should never perform any kind of blocking activity inside a go
block, because if every go block in work happens to end up blocked, you
will prevent all go blocks from making any further progress. It sounds to
me
My company has a production system that uses core.async extensively. We've
been running it 24/7 for over a year with occasional restarts to update
things and add features, and so far core.async has been working great.
The other day, during a particularly high workload, the whole system got
