* [PATCH] doc: mention kqueue/kevent alongside epoll
@ 2016-02-21 7:16 6% Eric Wong
0 siblings, 0 replies; 2+ results
From: Eric Wong @ 2016-02-21 7:16 UTC (permalink / raw)
To: yahns-public
epoll and kqueue are similar and we use them in a similar way;
so mention kqueue alongside epoll for users who may already be
familiar with kqueue on *BSD but not epoll under Linux.
epoll is a queue, too!
---
Documentation/design_notes.txt | 29 +++++++++++++++--------------
Documentation/yahns_config.pod | 7 ++++---
2 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/Documentation/design_notes.txt b/Documentation/design_notes.txt
index bf63617..308faa6 100644
--- a/Documentation/design_notes.txt
+++ b/Documentation/design_notes.txt
@@ -24,12 +24,12 @@ nothing but accepting sockets and injecting into to the event queue
worker thread pool
------------------
-This is where all the interesting application dispatch happens in yahns.
-epoll(2) (or kqueue(2)) descriptor is the heart of event queue. This
-design allows clients to migrate between different threads as they
-become active, preventing head-of-line blocking in traditional designs
-where a client is pinned to a thread (at the cost of weaker cache
-locality).
+This is where all the interesting application dispatch happens in
+yahns. A descriptor returned by epoll_create1(2) (or kqueue(2)) is
+the heart of event queue. This design allows clients to migrate
+between different threads as they become active, preventing
+head-of-line blocking in traditional designs where a client is
+pinned to a thread (at the cost of weaker cache locality).
The critical component for implementing this thread pool is "one-shot"
notifications in the epoll and kqueue APIs, allowing them to be used as
@@ -37,8 +37,8 @@ readiness queues for feeding the thread pool. Used correctly, this
allows us to guarantee exclusive access to a client socket without
additional locks managed in userspace.
-Idle threads will sit performing epoll_wait (or kqueue) indefinitely
-until a socket is reported as "ready" by the kernel.
+Idle threads will sit performing epoll_wait(2) (or kevent(2))
+indefinitely until a socket is reported as "ready" by the kernel.
queue flow
----------
@@ -46,7 +46,7 @@ queue flow
Once a client is accept(2)-ed, it is immediately pushed into the worker
thread pool (via EPOLL_CTL_ADD or EV_ADD). This mimics the effect of
TCP_DEFER_ACCEPT (in Linux) and the "dataready" accept filter (in
-FreeBSD) from the perspective of the epoll_wait(2)/kqueue(2) caller.
+FreeBSD) from the perspective of the epoll_wait(2)/kevent(2) caller.
No explicit locking controlled from userspace is necessary.
TCP_DEFER_ACCEPT/"dataready"/"httpready" themselves are not used as it
@@ -70,12 +70,13 @@ have completed processing.
"Yielding" a client is accomplished by re-arming the already "ready"
socket by using EPOLL_CTL_MOD (with EPOLLONESHOT) with a one-shot
-notification requeues the descriptor at the end of the internal epoll
-ready queue; achieving a similar effect to yielding a thread (via
-sched_yield or Thread.pass) in a purely multi-threaded design.
+notification requeues the descriptor at the end of the internal
+epoll (or kevent) ready queue; achieving a similar effect to
+yielding a thread (via sched_yield or Thread.pass) in a purely
+multi-threaded design.
-Once the client is yielded, epoll_wait is called again to pull
-the next client off the ready queue.
+Once the client is yielded, epoll_wait or kevent is called again to
+pull the next client off the ready queue.
Output buffering notes
----------------------
diff --git a/Documentation/yahns_config.pod b/Documentation/yahns_config.pod
index cc1ea71..3b1f2e4 100644
--- a/Documentation/yahns_config.pod
+++ b/Documentation/yahns_config.pod
@@ -110,7 +110,7 @@ be given without a block to associate an app block with a named
queue.
Usually, only one queue is necessary. Each queue corresponds to
-an epoll descriptor and worker thread pool.
+an epoll or kqueue descriptor and worker thread pool.
Default: NAME defaults to :default
@@ -161,9 +161,10 @@ Default: / if daemonized, current working directory if not
=item max_events INTEGER
This controls the number of events a worker thread will fetch at
-once via L<epoll_wait(2)>. There is no good reason to change this
+once via L<epoll_wait(2)> or L<kevent(2)>.
+There is no good reason to change this
unless you use very few (e.g. 1) worker_threads. Leaving this at
-1 will give the fairest load balancing behavior with epoll.
+1 will give the fairest load balancing behavior with epoll or kqueue.
Default: 1
--
EW
^ permalink raw reply related [relevance 6%]
* [ANN] yahns 1.12.1 -_- sleepy app server for Ruby
@ 2016-02-22 0:43 7% ` Eric Wong
0 siblings, 0 replies; 2+ results
From: Eric Wong @ 2016-02-22 0:43 UTC (permalink / raw)
To: ruby-talk, yahns-public
A Free Software, multi-threaded, non-blocking network
application server designed for low _idle_ power consumption.
It is primarily optimized for applications with occasional users
which see little or no traffic. yahns currently hosts Rack/HTTP
applications, but may eventually support other application
types. Unlike some existing servers, yahns is extremely
sensitive to fatal bugs in the applications it hosts.
Changes:
yahns 1.12.1 - more TLS fixes
Most notably release fixes TLS output buffering for large
responses to slow clients. For Rack HTTPS users,
env['SERVER_PORT'] also defaults to 443 properly unless the
Host: request header specifies differently.
Also, the extras/autoindex change is to make our own directory
listing look nicer as we use Let's Encrypt and don't want to
waste space listing ".well-known/" directory contents on:
https://yahns.yhbt.net/
Yes, we really do care how our homepage looks!
6 changes since v1.12.0:
extras/autoindex: support hiding dotfiles
fix output buffering with SSL_write
https: ensure SERVER_PORT defaults to 443
test_ssl: check SERVER_PORT when parsed from Host: header
doc: mention kqueue/kevent alongside epoll
doc: more minor updates
Please note the disclaimer:
yahns is extremely sensitive to fatal bugs in the apps it hosts. There
is no (and never will be) any built-in "watchdog"-type feature to kill
stuck processes/threads. Each yahns process may be handling thousands
of clients; unexpectedly killing the process will abort _all_ of those
connections. Lives may be lost!
yahns hackers are not responsible for your application/library bugs.
Use an application server which is tolerant of buggy applications
if you cannot be bothered to fix all your fatal bugs.
* git clone git://yhbt.net/yahns
* http://yahns.yhbt.net/README
* http://yahns.yhbt.net/NEWS.atom.xml
* we only accept plain-text email yahns-public@yhbt.net
* and archive all the mail we receive: http://yhbt.net/yahns-public/
* nntp://news.public-inbox.org/inbox.comp.lang.ruby.yahns
^ permalink raw reply [relevance 7%]
Results 1-2 of 2 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2016-02-14 22:37 [ANN] yahns 1.12.0 -_- sleepy app server for Ruby Eric Wong
2016-02-22 0:43 7% ` [ANN] yahns 1.12.1 " Eric Wong
2016-02-21 7:16 6% [PATCH] doc: mention kqueue/kevent alongside epoll Eric Wong
Code repositories for project(s) associated with this public inbox
https://yhbt.net/yahns.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).