NimNode Library

Search:

Author: Wang Tong
Version: 0.1.1

"You are not fighting alone!"

NimNode is a library for async programming and communication. This Library uses an event-driven, non-blocking I/O model based on libuv. Furthermore, you can use Future async/await in the standard library to construct logical workflow to simplify programming tasks. What is libuv? What is non-blocking I/O? What is event-driven? What are future and promise?

NimNode requires libuv library which should have been installed on your operating system. Releases are available as tags in this repository and can be fetched via nimble:

nimble install node

Core modules

  • error Provides error codes corresponding the libuv constants. NimNode use these codes to indicate an internal error which caused by libuv operations.
  • loop Loop is the central part of functionality which depends on libuv event loop. It takes care of polling for i/o and scheduling callbacks to be run based on different sources of events.
  • timers This module implements a timer dispatcher and a ticker dispatcher. A timer delays an operation after some milliseconds. A ticker delays an operation to the next iteration.
  • streams This module provides an abstraction of a duplex communication based on libuv. DuplexStream is an abstract interface which provides reading and writing for non-blocking I/O. There are 3 duplex implementations in the form of TcpStream, TtyStream, PipeStream.
  • nettype
  • net Provides an asynchronous network wrapper. It contains procedures for creating both servers and clients (called streams).
  • uv This module is a raw wrapper of libuv. It contains several sub modules.
    • uv_error In libuv errors are negative numbered constants. As a rule of thumb, whenever there is a status parameter, or an API procedures returns an integer, a negative number will imply an error.
    • uv_version Starting with version 1.0.0 libuv follows the semantic versioning scheme. This means that new APIs can be introduced throughout the lifetime of a major release. In this section you’ll find all macros and procedures that will allow you to write or compile code conditionally, in order to work with multiple libuv versions.
    • uv_loop The event loop is the central part of libuv’s functionality. It takes care of polling for i/o and scheduling callbacks to be run based on different sources of events.
    • uv_handle The base type for all libuv handle types.
    • uv_request The base type for all libuv request types.
    • uv_timer Timer handles are used to schedule callbacks to be called in the future.
    • uv_prepare Prepare handles will run the given callback once per loop iteration, right before polling for i/o.
    • uv_check Check handles will run the given callback once per loop iteration, right after polling for i/o.
    • uv_idle Idle handles will run the given callback once per loop iteration, right before the prepare handles.
    • uv_async Async handles allow the user to “wakeup” the event loop and get a callback called from another thread.
    • uv_poll Poll handles are used to watch file descriptors for readability, writability and disconnection similar to the purpose of poll.
    • uv_signal Signal handles implement Unix style signal handling on a per-event loop bases.
    • uv_process Process handles will spawn a new process and allow the user to control it and establish communication channels with it using streams.
    • uv_stream Stream handles provide an abstraction of a duplex communication channel. stream is an abstract type, libuv provides 3 stream implementations in the for of tcp, pipe and tty.
    • uv_tcp TCP handles are used to represent both TCP streams and servers.
    • uv_pipe Pipe handles provide an abstraction over local domain sockets on Unix and named pipes on Windows.
    • uv_tty TTY handles represent a stream for the console.
    • uv_udp UDP handles encapsulate UDP communication for both clients and servers.
    • uv_fs_event FS Event handles allow the user to monitor a given path for changes, for example, if the file was renamed or there was a generic change in it. This handle uses the best backend for the job on each platform.
    • uv_fs_poll FS Poll handles allow the user to monitor a given path for changes. Unlike fs event, fs poll handles use stat to detect when a file has changed so they can work on file systems where fs event handles can’t.
    • uv_misc This section contains miscellaneous procedures that don’t really belong in any other section.