File: control

package info (click to toggle)
readerwriterqueue 1.0.3-1
  • links: PTS, VCS
  • area: main
  • in suites: bullseye
  • size: 388 kB
  • sloc: cpp: 2,876; makefile: 79
file content (42 lines) | stat: -rw-r--r-- 1,946 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Source: readerwriterqueue
Section: devel
Priority: optional
Maintainer: Debian Med Packaging Team <debian-med-packaging@lists.alioth.debian.org>
Uploaders: Steffen Moeller <moeller@debian.org>
Build-Depends: debhelper-compat (= 13), cmake
Standards-Version: 4.5.0
Homepage: https://github.com/cameron314/readerwriterqueue
Vcs-Browser: https://salsa.debian.org/med-team/readerwriterqueue
Vcs-Git: https://salsa.debian.org/med-team/readerwriterqueue.git
Rules-Requires-Root: no

Package: libreaderwriterqueue-dev
Architecture: all
Section: libdevel
Depends: ${misc:Depends}
Description: single-producer, single-consumer lock-free queue for C++
 This package provides a lock-free queue  for C++.  It only supports
 a two-thread use case (one consuming, and one producing). The threads
 can't switch roles, though you could use this queue completely from a
 single thread if you wish (but that would sort of defeat the purpose!).
 .
 Features:
  * Blazing fast
  * Compatible with C++11 (supports moving objects instead of making
  copies)
  * Fully generic (templated container of any type) -- just like
    std::queue, you never need to allocate memory for elements yourself
    (which saves you the hassle of writing a lock-free memory manager
    to hold the elements you're queueing)
  * Allocates memory up front, in contiguous blocks
  * Provides a try_enqueue method which is guaranteed never to allocate
    memory (the queue starts with an initial capacity)
  * Also provides an enqueue method which can dynamically grow the size
    of the queue as needed
  * Also provides try_emplace/emplace convenience methods
  * Has a blocking version with wait_dequeue
  * Completely "wait-free" (no compare-and-swap loop). Enqueue and
    dequeue are always O(1) (not counting memory allocation)
  * On x86, the memory barriers compile down to no-ops, meaning enqueue
    and dequeue are just a simple series of loads and stores (and
    branches)