This commit changes how the event loop determines if it needs to stay alive. Previously, an internal counter was increased whenever a handle got created and decreased again when the handle was closed. While conceptually simple, it turned out hard to work with: you often want to keep the event loop alive only if the handle is actually doing something. Stopped or inactive handles were a frequent source of hanging event loops. That's why this commit changes the reference counting scheme to a model where a handle only references the event loop when it's active. 'Active' means different things for different handle types, e.g.: * timers: ticking * sockets: reading, writing or listening * processes: always active (for now, subject to change) * idle, check, prepare: only active when started This commit also changes how the uv_ref() and uv_unref() functions work: they now operate on the level of individual handles, not the whole event loop. The Windows implementation was done by Bert Belder. |
||
|---|---|---|
| build | ||
| include | ||
| src | ||
| test | ||
| .gitignore | ||
| .mailmap | ||
| .travis.yml | ||
| AUTHORS | ||
| common.gypi | ||
| config-mingw.mk | ||
| config-unix.mk | ||
| gyp_uv | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| uv.gyp | ||
| vcbuild.bat | ||
libuv 
libuv is a new platform layer for Node. Its purpose is to abstract IOCP on Windows and libev on Unix systems. We intend to eventually contain all platform differences in this library.
Features
-
Non-blocking TCP sockets
-
Non-blocking named pipes
-
UDP
-
Timers
-
Child process spawning
-
Asynchronous DNS via c-ares or
uv_getaddrinfo. -
Asynchronous file system APIs
uv_fs_* -
High resolution time
uv_hrtime -
Current executable path look up
uv_exepath -
Thread pool scheduling
uv_queue_work -
ANSI escape code controlled TTY
uv_tty_t -
File system events Currently supports inotify,
ReadDirectoryChangesWand kqueue. Event ports in the near future.uv_fs_event_t -
IPC and socket sharing between processes
uv_write2
Documentation
See include/uv.h.
Build Instructions
For GCC (including MinGW) there are two methods building: via normal makefiles or via GYP. GYP is a meta-build system which can generate MSVS, Makefile, and XCode backends. It is best used for integration into other projects. The old (more stable) system is using Makefiles.
To build via Makefile simply execute:
make
To build with Visual Studio run the vcbuilds.bat file which will checkout the GYP code into build/gyp and generate the uv.sln and related files.
Windows users can also build from cmd-line using msbuild. This is done by running vcbuild.bat from Visual Studio command prompt.
To have GYP generate build script for another system you will need to checkout GYP into the project tree manually:
svn co http://gyp.googlecode.com/svn/trunk build/gyp
Unix users run
./gyp_uv -f make
make
Macintosh users run
./gyp_uv -f xcode
xcodebuild -project uv.xcodeproj -configuration Release -target All
Supported Platforms
Microsoft Windows operating systems since Windows XP SP2. It can be built with either Visual Studio or MinGW.
Linux 2.6 using the GCC toolchain.
MacOS using the GCC or XCode toolchain.
Solaris 121 and later using GCC toolchain.