Libuv ist eine Multi-Plattform-Support-Bibliothek mit Schwerpunkt auf asynchronem E/O. Es wurde hauptsächlich für den Einsatz von Node.js entwickelt, aber auch von Luvit, Julia, Uvloop und anderen verwendet.
Event-Schleife mit vollem Funktionsumfang von Epoll, Kqueue, IOCP, Event-Ports.
Asynchrone TCP- und UDP -Sockeln
Asynchrone DNS -Auflösung
Asynchrone Datei- und Dateisystemvorgänge
Dateisystemereignisse
ANSI Escape Code kontrolliert TTY
IPC mit Socket Sharing, Verwenden von UNIX -Domänen -Sockets oder benannten Pipes (Windows)
Kinderprozesse
Fadenpool
Signalhandhabung
Hochauflösende Uhr
Faden- und Synchronisationsprimitive
Beginnend mit der Version 1.0.0 Libuv folgt dem semantischen Versionsschema. Die API -Änderung und die Rückwärtskompatibilitätsregeln sind diejenigen, die von Semver angegeben sind. Libuv wird einen stabilen ABI über wichtige Veröffentlichungen hinweg behalten.
Die ABI/API -Änderungen können hier verfolgt werden.
Libuv ist unter der MIT -Lizenz lizenziert. Überprüfen Sie die Lizenz- und Lizenz-Extra-Dateien.
Die Dokumentation ist unter der CC durch 4.0 Lizenz lizenziert. Überprüfen Sie die lizenzdocs-Datei.
Befindet sich in den docs/ subd Directory. Es verwendet das Sphinx -Framework, das es ermöglicht, die Dokumentation in mehreren Formaten zu erstellen.
Zeigen Sie verschiedene unterstützte Gebäudeoptionen:
$ make helpDokumentation als HTML erstellen:
$ make htmlErstellen Sie die Dokumentation als HTML und Live laden sie neu, wenn sie sich ändert (dies erfordert, dass Sphinx-autobuild installiert werden muss und nur bei UNIX unterstützt wird):
$ make livehtmlErstellen Sie Dokumentation als Mannseiten:
$ make manDokumentation als epub erstellen:
$ make epubHinweis: Windows -Benutzer müssen make.bat anstelle von einfach 'make' verwenden.
Die Dokumentation kann hier online gestrichen werden.
Die Tests und Benchmarks dienen auch als API -Spezifikations- und Verwendungsbeispiele.
Diese Ressourcen werden nicht von Libuv -Betreuern behandelt und sind möglicherweise veraltet. Bitte überprüfen Sie es, bevor Sie neue Probleme eröffnen.
Libuv kann entweder aus dem Github -Repository oder von der Download -Site heruntergeladen werden.
Vor der Überprüfung der GIT -Tags oder Signaturdateien ist das Importieren der entsprechenden Schlüssel erforderlich. Schlüssel -IDs sind in der Wartenerdatei aufgeführt, sind aber auch als Git -Blob -Objekte verfügbar, um sie einfacher zu verwenden.
Importieren eines Schlüssels auf übliche Weise:
$ gpg --keyserver pool.sks-keyservers.net --recv-keys AE9BC059Importieren eines Schlüssels aus einem Git -Blob -Objekt:
$ git show pubkey-saghul | gpg --importGit -Tags sind mit dem Schlüssel des Entwicklers signiert, sie können wie folgt überprüft werden:
$ git verify-tag v1.6.1Ab Libuv 1.7.0 sind die auf der Download -Site gespeicherten Tarballs signiert und eine begleitende Signaturdatei sitzt neben jedem. Sobald sowohl der Release -Tarball als auch die Signaturdatei heruntergeladen wurden, kann die Datei wie folgt überprüft werden:
$ gpg --verify libuv-1.7.0.tar.gz.signFür Unix-ähnliche Plattformen, einschließlich MacOS, gibt es zwei Build-Methoden: Autotools oder CMake.
Für Windows ist CMake die einzige unterstützte Build -Methode und hat die folgenden Voraussetzungen:
PATH enthalten sein können.Mit Autotools bauen:
$ sh autogen.sh
$ ./configure
$ make
$ make check
$ make installMit CMake bauen:
$ 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 buildMit CMAKE zusammenkompilieren (nicht unterstützt, aber im Allgemeinen funktioniert):
$ cmake ../..
-DCMAKE_SYSTEM_NAME=Windows
-DCMAKE_SYSTEM_VERSION=6.1
-DCMAKE_C_COMPILER=i686-w64-mingw32-gcc$ brew install --HEAD libuvHinweis an OS X -Benutzer:
Stellen Sie sicher, dass Sie die Architektur angeben, für die Sie in der Flagge "Bogen" erstellen möchten. Sie können mehr als einen angeben, indem Sie mit einem Raum abgrenzen (z. B. "x86_64 i386").
$ git clone https://github.com/microsoft/vcpkg.git
$ ./bootstrap-vcpkg.bat # for powershell
$ ./bootstrap-vcpkg.sh # for bash
$ ./vcpkg install libuvSie können vorgefertigte Binärdateien für Libuv installieren oder sie mit Conan aus der Quelle erstellen. Verwenden Sie den folgenden Befehl:
conan install --requires= " libuv/[*] " --build=missingDas Libuv Conan -Rezept wird von Conan -Betreuern und Community -Mitwirkenden auf dem neuesten Stand gehalten. Wenn die Version veraltet ist, erstellen Sie bitte eine Ausgabe- oder Zuganfrage im ConancenterIndex -Repository.
Einige Tests sind timingempfindlich. Bei langsamen oder überlasteten Maschinen können entspannende Testzeitüberschreitungen erforderlich sein:
$ env UV_TEST_TIMEOUT_MULTIPLIER=2 build/uv_run_tests # 10s instead of 5s Die Liste aller Tests befindet sich in test/test-list.h .
Dieser Aufruf veranlasst den Testtreiber, TEST_NAME in einem untergeordneten Prozess zu gib und auszuführen:
$ build/uv_run_tests_a TEST_NAMEDieser Aufruf führt dazu, dass der Testfahrer den Test im selben Prozess ausführt:
$ build/uv_run_tests_a TEST_NAME TEST_NAME Wenn Sie den Test aus dem Testfahrerprozess ausführen ( build/uv_run_tests_a TEST_NAME TEST_NAME ), funktionieren Tools wie GDB und Valgrind normal.
Verwenden Sie diese Tools, wenn Sie den Test aus einem Kind des Test-Treiberprozesses ( build/uv_run_tests_a TEST_NAME ) auf gabelbewusste Weise verwenden.
Verwenden Sie die Einstellung für den Follow-Gabel-Modus:
$ gdb --args build/uv_run_tests_a TEST_NAME
(gdb) set follow-fork-mode child
...
Verwenden Sie den Parameter --trace-children=yes :
$ 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 Siehe den Abschnitt zum Ausführen von Tests. Der Benchmark-Treiber ist ./uv_run_benchmarks_a und die Benchmarks sind in test/benchmark-list.h aufgeführt.
Überprüfen Sie die Datei der Supported_Platforms.
-fno-strict-aliasing Es wird empfohlen, das FLAG -fno-strict-aliasing -Compiler in Projekten einzuschalten, die Libuv verwenden. Die Verwendung von Ad -hoc -Vererbung in der Libuv -API ist möglicherweise nicht sicher in Gegenwart von Compiler -Optimierungen, die vom strengen Aliasing abhängen.
MSVC hat keine äquivalente Flagge, es scheint es jedoch auch zum Zeitpunkt des Schreibens (Dezember 2019) nicht zu benötigen.)
Die AIX -Kompilierung mit IBM XL C/C ++ erfordert Version 12.1 oder höher.
Die AIX-Unterstützung für Dateisystemereignisse erfordert, dass das nicht-definierte IBM bos.ahafs Paket installiert wird. Dieses Paket bietet die AIX -Ereignisinfrastruktur, die von autoconf erkannt wird. Die IBM -Dokumentation beschreibt das Paket genauer.
Die Zoslib -Kompilierung muss installiert werden. Verwenden Sie beim Erstellen mit CMake das Flag -DZOSLIB_DIR , um den Pfad zu Zoslib anzugeben:
$ (cd build && cmake .. -DBUILD_TESTING=ON -DZOSLIB_DIR=/path/to/zoslib)
$ cmake --build buildZ/OS erstellt System -V -Semaphoren und Nachrichtenwarteschlangen. Diese bestehen am System, nachdem der Prozess beendet wird, es sei denn, die Ereignisschleife ist geschlossen.
Verwenden Sie den Befehl ipcrm , um System -v -Ressourcen manuell zu löschen.
Siehe die Richtlinien für den Beitrag.