Cross-platform asynchronous I/O

Overview

libuv

Overview

libuv is a multi-platform support library with a focus on asynchronous I/O. It was primarily developed for use by Node.js, but it's also used by Luvit, Julia, pyuv, and others.

Feature highlights

  • Full-featured event loop backed by epoll, kqueue, IOCP, event ports.

  • Asynchronous TCP and UDP sockets

  • Asynchronous DNS resolution

  • Asynchronous file and file system operations

  • File system events

  • ANSI escape code controlled TTY

  • IPC with socket sharing, using Unix domain sockets or named pipes (Windows)

  • Child processes

  • Thread pool

  • Signal handling

  • High resolution clock

  • Threading and synchronization primitives

Versioning

Starting with version 1.0.0 libuv follows the semantic versioning scheme. The API change and backwards compatibility rules are those indicated by SemVer. libuv will keep a stable ABI across major releases.

The ABI/API changes can be tracked here.

Licensing

libuv is licensed under the MIT license. Check the LICENSE file. The documentation is licensed under the CC BY 4.0 license. Check the LICENSE-docs file.

Community

Documentation

Official documentation

Located in the docs/ subdirectory. It uses the Sphinx framework, which makes it possible to build the documentation in multiple formats.

Show different supported building options:

$ make help

Build documentation as HTML:

$ make html

Build documentation as HTML and live reload it when it changes (this requires sphinx-autobuild to be installed and is only supported on Unix):

$ make livehtml

Build documentation as man pages:

$ make man

Build documentation as ePub:

$ make epub

NOTE: Windows users need to use make.bat instead of plain 'make'.

Documentation can be browsed online here.

The tests and benchmarks also serve as API specification and usage examples.

Other resources

  • LXJS 2012 talk — High-level introductory talk about libuv.
  • libuv-dox — Documenting types and methods of libuv, mostly by reading uv.h.
  • learnuv — Learn uv for fun and profit, a self guided workshop to libuv.

These resources are not handled by libuv maintainers and might be out of date. Please verify it before opening new issues.

Downloading

libuv can be downloaded either from the GitHub repository or from the downloads site.

Before verifying the git tags or signature files, importing the relevant keys is necessary. Key IDs are listed in the MAINTAINERS file, but are also available as git blob objects for easier use.

Importing a key the usual way:

$ gpg --keyserver pool.sks-keyservers.net --recv-keys AE9BC059

Importing a key from a git blob object:

$ git show pubkey-saghul | gpg --import

Verifying releases

Git tags are signed with the developer's key, they can be verified as follows:

$ git verify-tag v1.6.1

Starting with libuv 1.7.0, the tarballs stored in the downloads site are signed and an accompanying signature file sit alongside each. Once both the release tarball and the signature file are downloaded, the file can be verified as follows:

$ gpg --verify libuv-1.7.0.tar.gz.sign

Build Instructions

For UNIX-like platforms, including macOS, there are two build methods: autotools or CMake.

For Windows, CMake is the only supported build method and has the following prerequisites:

  • One of:
    • Visual C++ Build Tools
    • Visual Studio 2015 Update 3, all editions including the Community edition (remember to select "Common Tools for Visual C++ 2015" feature during installation).
    • Visual Studio 2017, any edition (including the Build Tools SKU). Required Components: "MSbuild", "VC++ 2017 v141 toolset" and one of the Windows SDKs (10 or 8.1).
  • Basic Unix tools required for some tests, Git for Windows includes Git Bash and tools which can be included in the global PATH.

To build with autotools:

$ sh autogen.sh
$ ./configure
$ make
$ make check
$ make install

To build with CMake:

$ mkdir -p build

$ (cd build && cmake .. -DBUILD_TESTING=ON) # generate project with tests
$ cmake --build build                       # add `-j <n>` with cmake >= 3.12

# Run tests:
$ (cd build && ctest -C Debug --output-on-failure)

# Or manually run tests:
$ build/uv_run_tests                        # shared library build
$ build/uv_run_tests_a                      # static library build

To cross-compile with CMake (unsupported but generally works):

$ cmake ../..                 \
  -DCMAKE_SYSTEM_NAME=Windows \
  -DCMAKE_SYSTEM_VERSION=6.1  \
  -DCMAKE_C_COMPILER=i686-w64-mingw32-gcc

Install with Homebrew

$ brew install --HEAD libuv

Note to OS X users:

Make sure that you specify the architecture you wish to build for in the "ARCHS" flag. You can specify more than one by delimiting with a space (e.g. "x86_64 i386").

Running tests

Some tests are timing sensitive. Relaxing test timeouts may be necessary on slow or overloaded machines:

$ env UV_TEST_TIMEOUT_MULTIPLIER=2 build/uv_run_tests # 10s instead of 5s

Run one test

The list of all tests is in test/test-list.h.

This invocation will cause the test driver to fork and execute TEST_NAME in a child process:

$ build/uv_run_tests_a TEST_NAME

This invocation will cause the test driver to execute the test in the same process:

$ build/uv_run_tests_a TEST_NAME TEST_NAME

Debugging tools

When running the test from within the test driver process (build/uv_run_tests_a TEST_NAME TEST_NAME), tools like gdb and valgrind work normally.

When running the test from a child of the test driver process (build/uv_run_tests_a TEST_NAME), use these tools in a fork-aware manner.

Fork-aware gdb

Use the follow-fork-mode setting:

$ gdb --args build/uv_run_tests_a TEST_NAME

(gdb) set follow-fork-mode child
...
Fork-aware valgrind

Use the --trace-children=yes parameter:

$ valgrind --trace-children=yes -v --tool=memcheck --leak-check=full --track-origins=yes --leak-resolution=high --show-reachable=yes --log-file=memcheck-%p.log build/uv_run_tests_a TEST_NAME

Running benchmarks

See the section on running tests. The benchmark driver is ./uv_run_benchmarks_a and the benchmarks are listed in test/benchmark-list.h.

Supported Platforms

Check the SUPPORTED_PLATFORMS file.

-fno-strict-aliasing

It is recommended to turn on the -fno-strict-aliasing compiler flag in projects that use libuv. The use of ad hoc "inheritance" in the libuv API may not be safe in the presence of compiler optimizations that depend on strict aliasing.

MSVC does not have an equivalent flag but it also does not appear to need it at the time of writing (December 2019.)

AIX Notes

AIX compilation using IBM XL C/C++ requires version 12.1 or greater.

AIX support for filesystem events requires the non-default IBM bos.ahafs package to be installed. This package provides the AIX Event Infrastructure that is detected by autoconf. IBM documentation describes the package in more detail.

z/OS Notes

z/OS compilation requires ZOSLIB to be installed. When building with CMake, use the flag -DZOSLIB_DIR to specify the path to ZOSLIB:

$ (cd build && cmake .. -DBUILD_TESTING=ON -DZOSLIB_DIR=/path/to/zoslib)
$ cmake --build build

z/OS creates System V semaphores and message queues. These persist on the system after the process terminates unless the event loop is closed.

Use the ipcrm command to manually clear up System V resources.

Patches

See the guidelines for contributing.

Issues
  • Assertion failed: new_time >= loop->time

    Assertion failed: new_time >= loop->time

    • Version: 1.16.1
    • Platform: Windows 7 64 Bit

    Using latest node.js (libuv version 1.16.1) on my machine, causes the following error: Assertion failed: new_time >= loop->time, file src\win\timer.c, line 37

    I'm using a non overclocked AMD FX-6300. Yesterday it worked fine, but after a reboot it does not work anymore.

    question windows 
    opened by Jan-Kruse 123
  • fs: implement uv_fs_mkstemp on unix

    fs: implement uv_fs_mkstemp on unix

    Follow-up of https://github.com/nodejs/node/issues/5332

    I unfortunately don't have windows available.

    The win code will have to be refactored to use fs__mkdtemp's code. As far as I can see, the easiest way would be to pass a function pointer to either create a folder or a file.

    I'm aware that the windows side is the most painful, code-wise. This PR is just a basis to encourage someone else to do the windows side. No bad feeling if this doesn't get done, I'd completely understand.

    enhancement stalled 
    opened by ralt 80
  • fs: add uv_fs_utime_ex and uv_fs_futime_ex

    fs: add uv_fs_utime_ex and uv_fs_futime_ex

    These new functions behave identicaly to uv_fs_utime and uv_fs_futime respectively for every OS other than OS X and Windows. For OS X and Windows these new APIs will allow you to alter the birth/creation time of the file as well as the access and modify times.

    Fixes #499

    v2 
    opened by whitlockjc 76
  • Unix fork survival

    Unix fork survival

    As per the discussion on the mailing list, this is the beginning of an attempt to make libuv survive fork. I'm sure there's a lot that needs changed and done still, but it works, so I'm ready to open the PR with this proof of concept for further discussion.

    Some points:

    • There's a small but reasonable test suite. timers, async, fs_event watchers, the threadpool, poll watchers are all tested. Mac OS X and Linux are tested to work, with one exception (below).
    • The truly global state (the signal lock pipe and the threadpool) are automatically re-initialized with pthread_atfork
    • For loop-local state, this version uses a libev-like design where the user is expected to call uv_loop_fork following a fork. This function delegates to backend-specific functions as needed. (It is less complicated than libev's version because the kqueue and epoll state seems to be created each time uv__io_poll is called, so there's no need to "rearm" all the fds at fork time.)
    • Other backends besides linux, sunos, and kqueue will need to implement the appropriate function still. If they're like kqueue and linux, it's probably fairly trivial.
    • An alternative to an explicit uv_loop_fork call would be to have the main loop of uv_run monitor the current pid and compare it to the pid it was previously using, and then call an internal uv__loop_fork function. This adds the overhead of an extra syscall on each loop iteration, even for applications that don't intend to fork, whereas the explicit approach only costs those applications that do fork.
    • I used close in the implementation of uv_loop_fork instead of uv__close because it's possible, I think, that some fds could still be at -1 and extra error handling didn't seem warranted. I could be all wrong about that.

    There's one unresolved issue:

    • On OS X, CFRunLoop can't be used after a process has forked. This comes up if a directory uv_fs_event_t watcher was created in the parent. Attempting to re-create the CFRunLoop in the child, or even shut it down cleanly, causes the child process to abort. This isn't an issue for gevent currently because we don't use uv_fs_event_t (we use uv_fs_poll_t), but it's definitely a crack in the facade. I'm not sure how best to handle this. Thoughts?
    opened by jamadden 71
  • Add API for measuring event loop idle time

    Add API for measuring event loop idle time

    This PR contains code that I've been working on for a while as part of some research I've been doing at work, and decided it would be good to submit this for review after seeing @indutny's Node.js PR https://github.com/nodejs/node/pull/32018.

    The main reasons for writing this patch are:

    • Have very accurate measurements of idle time spent in the kernel's event provider.
    • Allow retrieval of the idle time from another thread to allow more accurate time-series data collection (instead of only collecting the data when the event loop can process a callback).

    A lot is explain in the commit message below, and I'll be happy to explain in detail why the implementation was done this way. For example, this approach was a conclusion I came to last year after researching whether it was possible to infer the state of the application based solely on event loop metrics. In order to achieve that goal it's necessary to have the level of accuracy this patch provides.

    There are a few things I'm unsure about and would like feedback on, like how I've implemented atomics, and I'll need some assistance with the Windows implementation.

    /cc @bnoordhuis @indutny @saghul

    Commit message:

    Add API for measuring event loop idle time

    The API addition uv_metrics_idle_time() is a thread safe call that allows the user to retrieve the amount of time the event loop has spent in the kernel's event provider (i.e. poll). It was done this way to allow retrieving this value without needing to interrupt the execution of the event loop. This option can be enabled by passing UV_METRICS_IDLE_TIME to uv_loop_configure().

    One important aspect of this change is, when enabled, to always first call the event provider with a timeout == 0. This allows libuv to know whether any events were waiting in the event queue when the event provider was called. The importance of this is because libuv is tracking the amount of "idle time", not "poll time". Thus the provider entry time is not recorded when timeout == 0 (the event provider never idles in this case).

    While this does add a small amount of overhead, when enabled, but the overhead decreases when the event loop has a heavier load. This is because poll events will be waiting when the event provider is called. Thus never actually recording the provider entry time.

    Checking if uv_loop_t is configured with UV_METRICS_IDLE_TIME always happens in uv__metrics_set_provider_entry_time() and uv__metrics_update_idle_time(). Making the conditional logic wrapping each call simpler and allows for instrumentation to always hook into those two function calls.

    Add struct uv__metrics_loop_t as a location for future metrics API additions.

    Add struct uv__loop_internal_fields_t as a location for future additions to uv_loop_t while also maintaining v1.x compatibility. A pointer to this struct has been placed in the uv_loop_t::unused[1] space to allow for fast retrieval and maintaining ABI compatibility with v1.x.

    Currently uv__loop_internal_fields_t only contains both the uv__metrics_loop_t and flags field. The reason for adding the flags field is because the same field was never added to UV_LOOP_PRIVATE_FIELDS in Windows as it was in Unix, and adding that field would break ABI.

    The idea for creating a struct and attaching it to uv_loop_t for future API enhancements was taken from a comment by bnoordhuis in: https://github.com/libuv/libuv/issues/2506#issuecomment-540050665

    Tests and additional documentation has been included.

    opened by trevnorris 70
  • build: make libuv buildable with vs2017

    build: make libuv buildable with vs2017

    Re: #1283

    This is the minimal change needed to get this to build on VS2017, it assumes the dev has run vsvarsall.bat (i.e. set-up the dev environment, and chose target and host arch) So to get it to build on appveyor you need to add to the YAML:

    before_build:
      - cmd: "C:\Program Files (x86)\Microsoft Visual Studio 15.0\VC\Auxiliary\Build\vcvarsall.bat amd64"
    

    I could add another PR with VS2017 detection code...

    opened by refack 70
  • doc: re-license documentation as CC By 4.0

    doc: re-license documentation as CC By 4.0

    I propose we change the license for the documentation to this: https://creativecommons.org/licenses/by/4.0/

    I guess this needs approval from everyone who contributed to docs/, so here it goes, in order of contribution:

    @saghul, @cjihrig, @neojski, @orangemocha, @bnoordhuis, @mkrufky, @jgeralnik, @creationix, @wavexx, @almosnow, @txdv, @beevik, @coreyfarrell, @dharesign, @Soarez, @yosuke-furukawa, @MostAwesomeDude, @btrask, @mscdex, @deleisha, @skeggse, @petkaantonov, @jhamhader, @bonifaido, @santigimeno, @Gottox, @imran-iq, @jasongin, @pmderodat, @neevek, @skypjack, @lomew, @baremetalfreak, @vcunat, @alexhultman, @plafer, @danbev, @hhellyer

    If someone knows that is not required, please let me know and @libuv/collaborators will make the decision then :-)

    If agreement is reached I'll follow up with a PR.

    doc 
    opened by saghul 69
  • win: do not read more from stream than available

    win: do not read more from stream than available

    On Windows the pipe implementation could read more from a stream than was available and it would create an assertion failure. This change will make it so we read the minimum of the available data or the length of the data.

    To test this, I took the existing ipc_send_recv_tcp test and updated it to do two writes and two read on each side of the pipe since that was the reproduction recipe used by the reporter. This approach reproduced the issue on Windows and the committed fix resolved the issue.

    Fixes #505

    opened by whitlockjc 67
  • add uv_device_t as stream on windows and Linux to handle device IO

    add uv_device_t as stream on windows and Linux to handle device IO

    reopen https://github.com/libuv/libuv/pull/379 older https://github.com/libuv/libuv/pull/19 oldest https://github.com/joyent/libuv/pull/1580

    TODO: rewrite simple test code.


    This change is Reviewable

    pending-review stalled stale 
    opened by zhaozg 64
  • fs: uv_fs_{open,read,close}_dir

    fs: uv_fs_{open,read,close}_dir

    This PR is for taking the efforts by @misterdjules in #175 and applying those changes to master instead of v1.x per @saghul's suggestion. You should be able to close #175 in favor of this but I'll leave that decision up to you.

    Note: This commit also updates uv__fs_readdir to use readdir instead of the deprecated readdir_r.

    v2 
    opened by whitlockjc 63
  •  unix: allow nbufs>IOV_MAX in uv_fs_read and uv_fs_write (replaces #269)

    unix: allow nbufs>IOV_MAX in uv_fs_read and uv_fs_write (replaces #269)

    Building on the excellent work of @bwijen, I was hoping to move the PR from March forward by addressing the last remaining concerns.

    This PR also unblocks it from merging, as there currently is a merge conflict on #269.

    Of course if @bwijen has time to review this PR or address the issues in his own PR #269, that would be most appreciated. In any case, he deserves the credit for the contribution. I'm just trying to help get it to the finish line, as I would really like to see it land. It has a big positive performance impact on io.js.

    cc @saghul, @bnoordhuis

    opened by ronkorving 53
  • z/OS builds broken: `fatal error: 'stdatomic.h' file not found`

    z/OS builds broken: `fatal error: 'stdatomic.h' file not found`

    • Version: v1.x
    • Platform: z/OS

    It looks like https://github.com/libuv/libuv/pull/3688 has broken the z/OS CI. e.g. https://ci.nodejs.org/view/libuv/job/libuv-test-commit-zos-cmake/1349/BUILDTYPE=Release,nodes=zos-s390x/console

    /u/iojs/build/workspace/libuv-test-commit-zos-cmake/BUILDTYPE/Release/nodes/zos-s390x/src/unix/async.c:29:10: fatal error: 'stdatomic.h' file not found
    #include <stdatomic.h>
             ^~~~~~~~~~~~~
    8 warnings and 1 error generated.
    Error while processing /u/iojs/build/workspace/libuv-test-commit-zos-cmake/BUILDTYPE/Release/nodes/zos-s390x/src/unix/async.c.
    CCN0793(I) Compilation failed for file /u/iojs/build/workspace/libuv-test-commit-zos-cmake/BUILDTYPE/Release/nodes/zos-s390x/src/unix/async.c.  Object file not created.
    CMakeFiles/uv_a.dir/build.make:326: recipe for target 'CMakeFiles/uv_a.dir/src/unix/async.c.o' failed
    make: *** [CMakeFiles/uv_a.dir/src/unix/async.c.o] Error 12
    

    cc @libuv/zos

    zos 
    opened by richardlau 2
  • linux: support hierarchies and cgroup2 for mem constraint lookup (rebase)

    linux: support hierarchies and cgroup2 for mem constraint lookup (rebase)

    Rebase of https://github.com/libuv/libuv/pull/2323, which I'm hoping to help push over the line.

    As far as I could see, here were only a couple of remaining review comments by @bnoordhuis:

    You parse /proc/self/mountinfo to determine if the system uses cgroups v1 or v2? Is that necessary? Doesn't the format of the memory field in /proc/self/cgroups tell you that?

    Would open("/sys/fs/cgroup/unified", O_DIRECTORY|O_CLOEXEC) work? It's a v2 system when it's there, it seems reasonable to assume v1 when it's not. (Related subject: I prefer openat() over path munging.)

    I don't know whether the cgroupv2 controller is guaranteed to be mounted at /sys/fs/cgroup/unified. The cgroups man pages only state that modern systemd auto-mounts the cgroup2 filesystem there, nothing more general. So for now, I've left the mountinfo parsing in, but happy to change that.

    I think it should fall back to /sys/fs/cgroup/memory/memory.limit_in_bytes if procfs isn't mounted. Right now it seems to default to 0, no limit.

    Done.

    cc @vtjnash @kjin

    opened by maleadt 1
  • win: optimize udp receive performance

    win: optimize udp receive performance

    Refs: https://github.com/nodejs/node/issues/43931

    Libuv either:

    1. Posts a "give me a datagram" IOCP request, or
    2. Queues up a "zero read" to get notified when new datagrams come in

    It should be possible in both cases to call WSARecvFrom() a few times to receive more pending datagrams. There should be a limit to avoid denial-of-service attacks. src/unix/udp.c limits it to 32 datagrams per event loop tick.

    https://github.com/libuv/libuv/blob/6c692ad1cbcc5083ec90954a4b091b660aedfc10/src/win/udp.c#L488-L551

    windows good first issue not-stale 
    opened by bnoordhuis 1
  • unix: missing memory barrier in tty spinlock

    unix: missing memory barrier in tty spinlock

    There's currently no explicit memory barrier and it's therefore theoretically possible for uv_tty_set_mode() and uv_tty_reset_mode() to see stores in different order.

    However, uv_tty_reset_mode() makes a system call that has the same strongly serializing effect as a memory barrier and so it's probably an academic issue. Maybe a code comment calling that out is sufficient to close out this issue.

    opened by bnoordhuis 0
Releases(v1.44.2)
  • v1.44.2(Jul 12, 2022)

    See https://github.com/libuv/libuv/issues/3586 for details.

    Dist files at https://dist.libuv.org/dist/v1.44.2/

    Important bugs fixed

    • loop: better align order-of-events behavior between platforms #3598
    • zos: fix fs event not fired if the watched file is moved/removed/recreated #3540
    • win: Fix pipe resource leak if closed during connect (and other bugs) #3611
    • zos: don't error when killing a zombie process #3625

    Regressions fixed

    • macos: avoid posix_spawnp() cwd bug #3597
    • kqueue: skip EVFILT_PROC events when invalidating events for an fd. #3629
    Source code(tar.gz)
    Source code(zip)
  • v1.44.1(Mar 9, 2022)

    See https://github.com/libuv/libuv/issues/3522 for details.

    Dist files at https://dist.libuv.org/dist/v1.44.1/

    Important bugs fixed

    • macos: don't use thread-unsafe strtok() in https://github.com/libuv/libuv/pull/3524
    • process: fix hang after NOTE_EXIT in https://github.com/libuv/libuv/pull/3521
    Source code(tar.gz)
    Source code(zip)
  • v1.44.0(Mar 7, 2022)

  • v1.43.0(Jan 4, 2022)

  • v1.42.0(Jul 22, 2021)

Cross-platform, efficient, customizable, and robust asynchronous HTTP/WebSocket server C++14 library with the right balance between performance and ease of use

What Is RESTinio? RESTinio is a header-only C++14 library that gives you an embedded HTTP/Websocket server. It is based on standalone version of ASIO

Stiffstream 871 Aug 9, 2022
A tiny cross-platform webview library for C/C++/Golang to build modern cross-platform GUIs.

webview for golang and c/c++ A tiny cross-platform webview library for C/C++/Golang to build modern cross-platform GUIs. The goal of the project is to

polevpn 14 Jul 5, 2022
cpp_redis is a C++11 Asynchronous Multi-Platform Lightweight Redis Client

C++11 Lightweight Redis client: async, thread-safe, no dependency, pipelining, multi-platform

CPP Redis 513 Aug 2, 2022
Microsoft 2.4k Aug 7, 2022
The Leap Motion cross-format, cross-platform declarative serialization library

Introduction to LeapSerial LeapSerial is a cross-format, declarative, serialization and deserialization library written and maintained by Leap Motion.

Leap Motion (Ultraleap) 15 Jan 17, 2022
A cross platform shader language with multi-threaded offline compilation or platform shader source code generation

A cross platform shader language with multi-threaded offline compilation or platform shader source code generation. Output json reflection info and c++ header with your shaders structs, fx-like techniques and compile time branch evaluation via (uber-shader) "permutations".

Alex Dixon 275 Jul 18, 2022
Reckless logging. Low-latency, high-throughput, asynchronous logging library for C++.

Introduction Reckless is an extremely low-latency, high-throughput logging library. It was created because I needed to perform extensive diagnostic lo

Mattias Flodin 438 Aug 3, 2022
Asynchronous Low Latency C++ Logging Library

Quill Asynchronous Low Latency C++ Logging Library Introduction Features Performance Supported Platforms And Compilers Basic Usage CMake Integration D

Odysseas Georgoudis 629 Aug 4, 2022
The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.

Welcome! The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design

Microsoft 7k Aug 6, 2022
Corvusoft's Restbed framework brings asynchronous RESTful functionality to C++14 applications.

Restbed Restbed is a comprehensive and consistent programming model for building applications that require seamless and secure communication over HTTP

Corvusoft 1.7k Aug 6, 2022
A C library for asynchronous DNS requests

c-ares This is c-ares, an asynchronous resolver library. It is intended for applications which need to perform DNS queries without blocking, or need t

c-ares 1.5k Aug 5, 2022
Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and 10K connections problem solution

CppServer Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and

Ivan Shynkarenka 867 Aug 8, 2022
Asynchronous networking for C

Overview Dyad.c is an asynchronous networking library which aims to be lightweight, portable and easy to use. It can be used both to create small stan

null 1.3k Aug 5, 2022
An asynchronous web framework for C++ built on top of Qt

!!! I can no longer maintain this project. If you're interessed, please contact me and I can move the projetct to you !!! Tufão - an asynchronous web

Vinícius dos Santos Oliveira 546 Aug 8, 2022
The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.

Welcome! The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design

Microsoft 7k Aug 8, 2022
Embeddable Event-based Asynchronous Message/HTTP Server library for C/C++

libasyncd Embeddable Event-based Asynchronous Message/HTTP Server library for C/C++. What is libasyncd? Libasyncd is an embeddable event-driven asynch

Seungyoung 165 May 25, 2022
Corvusoft's Restbed framework brings asynchronous RESTful functionality to C++14 applications.

Restbed Restbed is a comprehensive and consistent programming model for building applications that require seamless and secure communication over HTTP

Corvusoft 1.7k Aug 6, 2022
A C++ commandline for use in servers and chat software. Provides very simple asynchronous input/output.

commandline A C++ commandline for use in servers and terminal chat software. Provides very simple asynchronous input/output. Supports reading and writ

Lion 69 Aug 10, 2022
Corvusoft's Restbed framework brings asynchronous RESTful functionality to C++14 applications.

Restbed Restbed is a comprehensive and consistent programming model for building applications that require seamless and secure communication over HTTP

Corvusoft 1.4k Mar 8, 2021
Modern, asynchronous, and wicked fast C++11 client for Redis

redox Modern, asynchronous, and wicked fast C++11 client for Redis [] (https://travis-ci.org/hmartiro/redox) Redox is a C++ interface to the Redis key

Hayk Martiros 376 Jul 27, 2022
C++ Parallel Computing and Asynchronous Networking Engine

中文版入口 Sogou C++ Workflow As Sogou`s C++ server engine, Sogou C++ Workflow supports almost all back-end C++ online services of Sogou, including all sea

Sogou-inc 8.9k Aug 8, 2022
The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.

The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.

Microsoft 7k Aug 4, 2022
C++ Parallel Computing and Asynchronous Networking Engine

As Sogou`s C++ server engine, Sogou C++ Workflow supports almost all back-end C++ online services of Sogou, including all search services, cloud input method,online advertisements, etc., handling more than 10 billion requests every day. This is an enterprise-level programming engine in light and elegant design which can satisfy most C++ back-end development requirements.

Sogou-inc 8.9k Aug 8, 2022
An asynchronous directory file change watcher module for Windows, macOS and Linux wrapped for V

A V module for asynchronously watching for file changes in a directory. The module is essentially a wrapper for septag/dmon. It works for Windows, macOS and Linux.

null 16 Jul 29, 2022
Vis: Asynchronous 3D Visualization Tool

English | 简体中文 Vis: Asynchronous 3D Visualization Tool Vis 是一款交互式异步3D可视化工具,旨在让3D视觉和机器人应用开发更简单。 其核心功能包括: 图形绘制 3D模型文件导入 多种交互工具 Gzimo 安装 Linux # 安装必要的依

RVBUST 111 Aug 4, 2022
Enabling services on your device 70 Jul 31, 2022
C++ Parallel Computing and Asynchronous Networking Engine

As Sogou`s C++ server engine, Sogou C++ Workflow supports almost all back-end C++ online services of Sogou, including all search services, cloud input method,online advertisements, etc., handling more than 10 billion requests every day

Sogou Open Source 8.8k Aug 5, 2022
Idle is an asynchronous and hot-reloadable C++ dynamic component framework

Idle is an asynchronous, hot-reloadable, and highly reactive dynamic component framework similar to OSGI that is: ?? Modular: Your program logic is en

Denis Blank 165 Jul 28, 2022
Asynchronous gRPC with Boost.Asio executors

asio-grpc This library provides an implementation of boost::asio::execution_context that dispatches work to a grpc::CompletionQueue. Making it possibl

Dennis 138 Aug 8, 2022