libuv
v1.49.2: 2024.10.18, Version 1.49.2 (Stable)
Libuv est une bibliothèque de support multiplateforme en mettant l'accent sur les E / S asynchrones. Il a été principalement développé pour une utilisation par Node.js, mais il est également utilisé par Luvi, Julia, Uvloop et autres.
Boucle d'événement complète soutenue par Epoll, Kqueue, IOCP, Ports d'événements.
Sockets asynchrones TCP et UDP
Résolution DNS asynchrone
Opérations asynchrones de fichiers et de fichiers
Événements du système de fichiers
ANSI Escape Code contrôlé Tty
IPC avec partage de socket, à l'aide de sockets de domaine Unix ou de tuyaux nommés (Windows)
Processus enfants
Piscine
Manipulation du signal
Horloge haute résolution
Primitives de filetage et de synchronisation
En commençant par la version 1.0.0 Libuv suit le schéma de version sémantique. Les règles de modification de l'API et de compatibilité vers l'arrière sont celles indiquées par Semver. Libuv gardera un ABI stable à travers les grandes versions.
Les modifications ABI / API peuvent être suivies ici.
Libuv est autorisé sous la licence du MIT. Vérifiez les fichiers de licence et de licence-Extra.
La documentation est autorisée sous la licence CC par 4.0. Vérifiez le fichier Licence-Docs.
Situé dans les documents / sous-répertoire. Il utilise le framework Sphinx, ce qui permet de construire la documentation en plusieurs formats.
Afficher différentes options de construction prises en charge:
$ make helpConstruire la documentation comme HTML:
$ make htmlConstruire la documentation en tant que HTML et en direct le rechargez-le lorsqu'il change (cela nécessite l'installation de Sphinx-Autobuild et n'est pris en charge que sur Unix):
$ make livehtmlConstruire la documentation comme pages d'homme:
$ make manConstruire la documentation comme ePub:
$ make epubRemarque: Les utilisateurs de Windows doivent utiliser Make.bat au lieu de «faire» simple.
La documentation peut être parcourue en ligne ici.
Les tests et les repères servent également de spécification API et d'exemples d'utilisation.
Ces ressources ne sont pas gérées par les responsables de Libuv et pourraient être obsolètes. Veuillez le vérifier avant d'ouvrir de nouveaux problèmes.
Libuv peut être téléchargé à partir du référentiel GitHub ou du site de téléchargements.
Avant de vérifier les balises GIT ou les fichiers de signature, l'importation des clés pertinentes est nécessaire. Les ID clés sont répertoriés dans le fichier des maintenants, mais sont également disponibles en tant qu'objets Git Blob pour une utilisation plus facile.
Importation d'une clé de la manière habituelle:
$ gpg --keyserver pool.sks-keyservers.net --recv-keys AE9BC059Importation d'une clé à partir d'un objet Git Blob:
$ git show pubkey-saghul | gpg --importLes balises Git sont signées avec la clé du développeur, elles peuvent être vérifiées comme suit:
$ git verify-tag v1.6.1En commençant par Libuv 1.7.0, les Balls stockés sur le site de téléchargements sont signés et un fichier de signature qui l'accompagne est assis à côté de chacun. Une fois que le tarball de version et le fichier de signature sont téléchargés, le fichier peut être vérifié comme suit:
$ gpg --verify libuv-1.7.0.tar.gz.signPour les plates-formes de type UNIX, y compris le macOS, il existe deux méthodes de construction: AutoTools ou CMake.
Pour Windows, CMake est la seule méthode de construction prise en charge et possède les conditions suivantes:
PATH global.Pour construire avec AutoTools:
$ sh autogen.sh
$ ./configure
$ make
$ make check
$ make installPour construire avec 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 buildPour compiler avec CMake (non pris en charge mais fonctionne généralement):
$ cmake ../..
-DCMAKE_SYSTEM_NAME=Windows
-DCMAKE_SYSTEM_VERSION=6.1
-DCMAKE_C_COMPILER=i686-w64-mingw32-gcc$ brew install --HEAD libuvRemarque aux utilisateurs OS X:
Assurez-vous de spécifier l'architecture pour laquelle vous souhaitez construire dans l'indicateur "Archs". Vous pouvez en spécifier plusieurs en délimitant avec un espace (par exemple "x86_64 i386").
$ git clone https://github.com/microsoft/vcpkg.git
$ ./bootstrap-vcpkg.bat # for powershell
$ ./bootstrap-vcpkg.sh # for bash
$ ./vcpkg install libuvVous pouvez installer des binaires prédéfinis pour Libuv ou le construire à partir de la source à l'aide de Conan. Utilisez la commande suivante:
conan install --requires= " libuv/[*] " --build=missingLa recette de Libuv Conan est tenue à jour par les maintenseurs de Conan et les contributeurs communautaires. Si la version est obsolète, veuillez créer une demande de problème ou d'extraction sur le référentiel CongencerIndex.
Certains tests sont sensibles au timin. Des délais de test relaxants peuvent être nécessaires sur des machines lentes ou surchargées:
$ env UV_TEST_TIMEOUT_MULTIPLIER=2 build/uv_run_tests # 10s instead of 5s La liste de tous les tests est dans test/test-list.h .
Cette invocation fera en train de se débarrasser du pilote de test et d'exécuter TEST_NAME dans un processus enfant:
$ build/uv_run_tests_a TEST_NAMECette invocation amènera le pilote de test à exécuter le test dans le même processus:
$ build/uv_run_tests_a TEST_NAME TEST_NAME Lors de l'exécution du test à partir du processus du pilote de test ( build/uv_run_tests_a TEST_NAME TEST_NAME ), des outils comme GDB et Valgrind fonctionnent normalement.
Lorsque vous exécutez le test à partir d'un enfant du processus du pilote de test ( build/uv_run_tests_a TEST_NAME ), utilisez ces outils de manière consacrée à la fourche.
Utilisez le réglage du mode suivant:
$ gdb --args build/uv_run_tests_a TEST_NAME
(gdb) set follow-fork-mode child
...
Utilisez le paramètre --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 Voir la section sur les tests d'exécution. Le conducteur de référence est ./uv_run_benchmarks_a et les repères sont répertoriés dans test/benchmark-list.h .
Vérifiez le fichier pris en charge_platforms.
-fno-strict-aliasing Il est recommandé d'allumer l'indicateur de compilateur -fno-strict-aliasing dans des projets qui utilisent Libuv. L'utilisation de «héritage» ad hoc dans l'API Libuv peut ne pas être sûre en présence d'optimisations du compilateur qui dépendent d'un aliasage strict.
MSVC n'a pas de drapeau équivalent mais il ne semble pas non plus en avoir besoin au moment de la rédaction (décembre 2019.)
La compilation AIX utilisant IBM XL C / C ++ nécessite la version 12.1 ou plus.
La prise en charge AIX pour les événements de Système de fichiers nécessite l'installation du package IBM bos.ahafs non défaut. Ce package fournit l'infrastructure d'événements AIX détectée par autoconf . La documentation IBM décrit le package plus en détail.
La compilation Z / OS nécessite l'installation de Zoslib. Lorsque vous construisez avec CMake, utilisez le drapeau -DZOSLIB_DIR pour spécifier le chemin vers ZOSLIB:
$ (cd build && cmake .. -DBUILD_TESTING=ON -DZOSLIB_DIR=/path/to/zoslib)
$ cmake --build buildZ / OS crée des sémaphores System V et des files d'attente de messages. Ceux-ci persistent sur le système après la fin du processus à moins que la boucle d'événement ne soit fermée.
Utilisez la commande ipcrm pour effacer manuellement les ressources System V.
Voir les directives de contribution.
