大家好，这里有一个棘手的错误需要报告……我们在 ClojureScript 中的 Safari 7 环境下使用 core.async 时遇到一些问题。我们的应用围绕着一个大事件循环，该循环阻塞在来自众多用户活动或 API 调用的通道之一上收到消息。问题似乎出在这个事件循环中——我们使用 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 已连接。 (socket.js，第 309 行)
日志][向哈希为 19 的通道 put! (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! 回调给了我们 true (socket.js，第 89 行)
调试] Metronome：staff 数据解码。put! 完成：12.282ms (socket.js，第 93 行)
日志][向哈希为 19 的通道 put! (socket.js，第 86 行)
日志][消息是 [:metronome [:class-types [{:deletable false, :picture nil, :name "CycleCore", :id 2, :description "CycleCore 是一个 55 分钟的双项运动概念，结合了 30 分钟的... (socket.js，第 87 行)
日志][put! 回调给了我们 true (socket.js，第 89 行)
调试] Metronome：class-types 数据解码。put! 完成：1.288ms (socket.js，第 93 行)
日志][向哈希为 19 的通道 put! (socket.js，第 86 行)
日志][消息是 [:metronome [:locations [{:studios [{:deletable false, :name "Kensington", :id 1, :locationId 1, :description "Studio (11a) sits just off Stratford Road in Stratford Studios. To find us, just pass ... (socket.js，第 87 行)
调试] Metronome：locations 数据解码。put! 完成：0.884ms (socket.js，第 93 行)
请注意，我们在日志中看到了“alts! channel hashes”的条目，但我们从未看到“alts! unblocked”。然而，请注意传递给alts!的哈希列表。第19个频道被提及，但我们随后又将'put!'操作应用于第19个频道...但我们仍未获得解锁。一些让我感到可疑的事情，就是当我们被在"alts!"封锁时，对于只有一个元素绑定的频道，有两个"put!"操作成功立即执行。也许我误解了某些东西，但我不期望立即的"put!"回调被调用多次。有趣的是，最后一次"put!"没有调用回调。
不幸的是，这个错误的复现相当困难。我可以通过退出Safari，重新打开它并导航到开发服务器来有几分可靠地复现它。大约有1/15的尝试会以这种方式卡住。我想知道这与Safari的MessageChannel实现有关 - 你可以在日志条目中看到nexttick.js调用其回调，这看起来似是我浏览器中处理分发的方式。
我将非常乐意提供任何有用的信息，但这个问题的调试现在已经超出了我的能力。尽管代码是专有代码，但我愿意暂时将人员添加到GitHub项目中，以尝试修复这个问题。我们有开发API服务器，你可以指向这些服务器，所以这应该只是运行{{lein cljs}}的事情。
我已经附上了我们的Socket.io包装器和主事件循环的代码。遗憾的是，我还没有最小化测试用例 - 我不知道该从哪里开始。
