TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Disruptor: High performance alternative to bounded queues

2 点作者 sm_1024将近 2 年前

1 comment

rektide将近 2 年前
It&#x27;s weird to me what a splash this had at the time. I&#x27;m kind of forgetting what the essential adds are versus existing ring buffer systems?<p>Iirc mainly it&#x27;s that rather than there being a producer&#x2F;consumer role, there can be multiple work stages? An item might need to be extracted, transformed, and loaded, and item can stay in the queue while waiting for each stage before being done? This is how they get the dependency graph? Are there other major innovations here? <a href="https:&#x2F;&#x2F;lmax-exchange.github.io&#x2F;disruptor&#x2F;disruptor.html#_dependency_graphs" rel="nofollow">https:&#x2F;&#x2F;lmax-exchange.github.io&#x2F;disruptor&#x2F;disruptor.html#_de...</a><p>Recently notable, io_uring also has submission&#x2F;completion queues which are also ring buffers. Since the submission &amp; completion won&#x27;t necessarily be in order, since any given work item could take wildly different times, a lmax style item wouldn&#x27;t make sense; each ring buffer wants to be short lived in this impl.