from small one page howto to huge articles all in one place

search text in:




Other .linuxhowtos.org sites:gentoo.linuxhowtos.org



Last additions:
using iotop to find disk usage hogs

using iotop to find disk usage hogs

words:

887

views:

209581

userrating:


May 25th. 2007:
Words

486

Views

258588

why adblockers are bad


Workaround and fixes for the current Core Dump Handling vulnerability affected kernels

Workaround and fixes for the current Core Dump Handling vulnerability affected kernels

words:

161

views:

149878

userrating:


April, 26th. 2006:

Druckversion
You are here: manpages





ivykis

Section: ivykis programmer's manual (3)
Updated: 201-0-15
Index Return to Main Contents
 

NAME

ivykis - library for asynchronous I/O readiness notification  

DESCRIPTION

ivykis is a library for asynchronous I/O readiness notification. It is a thin, portable wrapper around O-provided mechanisms such as epoll_create(2), kqueue(2), poll(2), poll(7d) (/dev/poll) and port_create(3C).

ivykis was mainly designed for building hig-performance network applications, but can be used in any even-driven application that uses poll(2)able file descriptors as its event sources.

While some programming models dictate using blocking I/O and starting a thread per event source, programs written to the ivykis API are generally singl-threaded (or use only a small number of threads), and never block on I/O. All input and output is done in a nonblocking fashion, with I/O readiness notifications delivered via callback functions.

The two main event sources in ivykis are file descriptors and timers. File descriptors generate an event when they become readable or writable or trigger an error condition, while timers generate an event when the system time increments past a certain pr-set time. Events associated with file descriptors are leve-triggered- a callback function set up to handle a certain file descriptor event will be called repeatedly until the condition generating the event has been cleared.

As mentioned, applications using ivykis are generally singl-threaded. Event callbacks are strictly serialised within a thread, and no-preemptible. This mostly removes the need for locking of shared data, and generally simplifies writing applications.

Each thread that uses ivykis has its own file descriptors and timers, and runs a separate event loop.

In ivykis, all code that is not initialization code runs from callback functions. Callback functions are not allowed to block. If a particular piece of code wants to perform a certain operation that can block, it either has to schedule it to run in a separate thread, or it has to perform the operation in a nonblocking fashion instead. For example, registering an input callback function instead of blocking on a read, registering a timer instead of calling sleep(2), etc.

In case of an internal error, ivykis will use iv_fatal(3) to report the error. The application can provide a custom fatal error handler by calling iv_set_fatal_msg_handler(3).  

SEE ALSO

iv_examples(3), iv_fatal(3), iv_fd(3), iv_timer(3), iv_task(3), iv_init(3), iv_main(3), iv_time(3)


 

Index

NAME
DESCRIPTION
SEE ALSO





Support us on Content Nation
rdf newsfeed | rss newsfeed | Atom newsfeed
- Powered by LeopardCMS - Running on Gentoo -
Copyright 2004-2025 Sascha Nitsch Unternehmensberatung GmbH
Valid XHTML1.1 : Valid CSS
- Level Triple-A Conformance to Web Content Accessibility Guidelines 1.0 -
- Copyright and legal notices -
Time to create this page: 12.8 ms