大家好，这里有一个难以报告的问题... 我们在使用 ClojureScript 上的 core.async 时发现了一些问题。我们的应用程序围绕着一个大型的消息循环，该循环在来自许多与用户活动或 API 调用对应的通道之一的消息上阻塞。问题似乎存在于这个消息循环中 - 我们正在使用 alts! 从任何可用的通道中拉取消息，但有时日志显示我们到达 alts! 但永远不会解除阻塞。然而，通过更多的日志，我可以看到在 alts! 传递给 alts! 的通道列表中的通道之后有后续的写入，所以我实在不明白发生了什么事。
这就是高层次的概述，接下来是代码。
我们的主要消息循环如下
(log "进入主消息循环。")
(go
(while true
(log "alts! 通道哈希： " (map hash (:channels @app)))
(let [[message channel] (alts! (seq (:channels @app)))]
(log "alts! 解除阻塞，调用我们的 process-message"))
(swap! app process-message message channel)
(log "process-message 完成，循环"))))
{{process-message}} 是我们应用程序内部的一个函数，但我不认为它的细节是必不可少的。在 Safari 挂起的情况下，日志看起来像
[日志] process-message 完成，循环 (main.js，第 62 行)
[日志] alts! 通道哈希： (16 12 19 33) (main.js，第 82 行)
[日志] 套接字已连接。 (socket.js，第 309 行)
[日志] 将消息放入具有哈希 19 的通道中 (socket.js，第 86 行)
[日志] 消息是 [:metronome [:staff [{:description nil, :deletable true, :email nil, :isAdmin true, :isTrainer false, :telephone nil, :name "Fynder Admin", :picture nil, :userId 1} {:description nil, :deletable fa... (socket.js，第 87 行)
[日志] put! 回调给出 us true (socket.js，第 89 行)
[调试] Metronome：staff 数据解码。 put! 完成： 12.282ms (socket.js，第 93 行)
[日志] 将消息放入具有哈希 19 的通道中 (socket.js，第 86 行)
[日志] 消息是 [:metronome [:class-types [{:deletable false, :picture nil, :name "CycleCore", :id 2, :description "CycleCore 是一种 55 分钟的双练概念，结合了 30 分钟的高强度有氧运动 ... (socket.js，第 87 行)
[日志] put! 回调给出 us true (socket.js，第 89 行)
[调试] Metronome：class-types 数据解码。 put! 完成： 1.288ms (socket.js，第 93 行)
[日志] 将消息放入具有哈希 19 的通道中 (socket.js，第 86 行)
[日志] 消息是 [:metronome [:locations [{:studios [{:deletable false, :name "Kensington", :id 1, :locationId 1, :description "Studio (11a) 位于 Stratford 交通枢纽tad ... (socket.js，第 87 行)
【调试】节拍器：位置数据解码。写入完成：0.884毫秒（socket.js，第93行）
请注意，我们看到了“alts!信道散列”的日志条目，但我们从未看到“alts!解除阻塞”。然而，请注意传递给alts!的散列列表。19号信道被提及，但我们随后将其写入19号信道...但我们仍然没有得到解除阻塞。我也觉得有些可疑的是，当我们被阻塞在alts!时，对于仅绑定容纳一次元素的信道，两次put!调用立即成功。也许我理解错了，但我不会期望立即写入回调被调用不止一次。有趣的是，最后的put!没有调用回调。
很遗憾，这个错误的复现相当困难。我可以通过关闭Safari，重新打开它，然后导航到开发者服务器来相当可靠地复现它。大约有1/15的尝试会以这种方式卡住。我想知道这是否与Safari的MessageChannel实现有关 - 你可以在日志条目中看到nexttick.js调用其回调的地方，这看起来是我浏览器中派发的实现方式。
我会很高兴提供任何有用的信息，但这个错误超出了我的调试能力。虽然代码是专有的，但我会很乐意临时将人员加入到Github项目中，尝试修复这个问题。我们有开发API服务器，你可以指向它，所以这应该是运行{{lein cljs}}。
我已经附上了我们的Socket.io包装器和主事件循环代码。遗憾的是，我还没有最小化测试用例 - 我实在不知道从哪里开始。
