IndexedDB 的同步API 旨在用于Web 工作者内部:
同步 API 旨在仅在 Web Workers 内部使用。
但既然有一个异步 API,那么在 Web Worker 中使用同步 API 有什么意义。异步 API 无论如何都不会影响 UI 线程?
IndexedDB 的同步API 旨在用于Web 工作者内部:
同步 API 旨在仅在 Web Workers 内部使用。
但既然有一个异步 API,那么在 Web Worker 中使用同步 API 有什么意义。异步 API 无论如何都不会影响 UI 线程?
同步 API 比异步 API 更易于使用。Web Worker 不需要异步。
经过思考,web Worker 中需要异步,甚至认为后台线程同步 API 上看似不错的想法被证明是一个可怕的陷阱。
事实上,同步对于 IO 等待来说是假的。无论是异步还是同步,在内部它们都是相同的异步进程。Worker 应该在 IO 等待期间做一些有趣的 CPU 工作。
此外,我们可能已经有了 UI 线程的异步代码。重用异步代码比同时为前台编写异步代码和为后台编写同步代码更好。
Async API 可以使用不同的范围和模式创建多个事务。这些事务异步流是交错的。无法在同步 API 中交错交易。
我们在同步 API 上获得的唯一优势是易于使用。但是使用 promise/deferred 模式的异步工作流已经很好地解决了。
可能好的同步 API 是关键光标扫描过程(也适用于 UI 线程),因为它不涉及序列化并且可能不需要 IO。然而,尽管用例不同,但用于同步 API 的 IDBCursor 和用于异步 API 的 IDBCursorWithValue 会令人困惑。
对于编写高性能程序的开发人员来说,似乎同步 API 的好主意是一个可怕的陷阱。