MirrorHub/construct
0
0
Fork 0
mirror of https://github.com/matrix-construct/construct synced 2024-11-25 08:12:37 +01:00
Code Issues Releases Wiki Activity

ircd: Move IRCd Library section from top README.

Browse source
This commit is contained in:
Jason Volk 2018-02-15 18:32:03 -08:00
parent c6855c58c3
commit dbf6453171
2 changed files with 68 additions and 58 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

68
README.md
View file

@ -175,70 +175,22 @@ the number theoretic transform...
### IRCd Library
The purpose of `libircd` is to facilitate the execution of a server which
handles requests from end-users. The library hosts a set of pluggable modules
which may introduce the actual application features (or the "business logic")
of the server. These additional modules are found in the `modules/` directory;
This library can be embedded by developers creating their own server or those
who simply want to use the library of routines it provides.
##### libircd can be embedded in your application with very minimal overhead.
Including libircd headers will not include any other headers beyond those in
the standard library, with minimal impact on your project's compile complexity.
The prototypical embedding of `libircd` is `construct` found in the
`construct/` directory.
Linking to libircd from your executable allows you to customize and extend the
functionality of the server and have control over its execution, or, simply use
library routines provided by the library without any daemonization. Including
libircd headers will not include any other headers beyond those in the standard
library, with minimal impact on your project's compile complexity. The
prototypical embedding of `libircd` is `construct` found in the `construct/`
directory.
- Can be embedded in your application with very minimal overhead.
##### libircd runs only one server at a time.
- Runs only one server at a time.
Keeping with the spirit of simplicity of the original architecture, `libircd`
continues to be a "singleton" object which uses globals and keeps actual server
state in the library itself. In other words, **only one IRC daemon can exist
within a process's address space at a time.** Whether or not this was a pitfall
of the original design, it has emerged over the decades as a very profitable
decision for making IRCd an accessible open source internet project.
- Is asynchronous and single-threaded✝.
##### libircd is single-threaded✝
- Introduces its own userspace threading.
The library is based around the `boost::asio::io_service` event loop. It is
still an asynchronous event-based system. We process one event at a time;
developers must not block execution. While the `io_service` can be run safely
on multiple threads by the embedder's application, libircd will use a single
`io_service::strand`.
- Leverages fast & safe formal grammars.
This methodology ensures there is an _uninterrupted execution_ working through
a single event queue providing service. If there are periods of execution
which are computationally intense like parsing, hashing, cryptography, etc: this
is absorbed in lieu of thread synchronization and bus contention. Scaling this
system is done through running multiple instances which synchronize at the
application level.
✝ However, don't start assuming a truly threadless execution for the entire
address space. If there is ever a long-running background computation or a call
to a 3rd party library which will do IO and block the event loop, we may use an
additional `std::thread` to "offload" such an operation. Thus we do have
a threading model, but it is heterogeneous.
##### libircd introduces userspace threading✝
IRCd presents an interface introducing stackful coroutines, a.k.a. userspace
context switching, a.k.a. green threads, a.k.a. fibers. The library avoids callbacks
as the way to break up execution when waiting for events. Instead, we harken back
to the simple old ways of synchronous programming where control flow and data are
easy to follow.
✝ If there are certain cases where we don't want a stack to linger which may
jeopardize the c10k'ness of the daemon the asynchronous pattern is still used.
##### libircd leverages formal grammars
We utilize the `boost::spirit` system of parsing and printing through formal grammars,
rather than writing our own parsers manually. In addition, we build several tools
on top of such formal devices like a type-safe format string library acting as a
drop-in for `::sprintf()`, but accepting objects like `std::string` without `.c_str()`
and prevention of outputting unprintable/unwanted characters that may have been
injected into the system somewhere prior.
See the `include/ircd/` and `ircd/` directories for more information.

58
ircd/README.md
View file

@ -2,6 +2,64 @@
This directory contains definitions and linkage for `libircd`
The purpose of `libircd` is to facilitate the execution of a server which
handles requests from end-users. The library hosts a set of pluggable modules
which may introduce the actual application features (or the "business logic")
of the server. These additional modules are found in the `modules/` directory;
This library can be embedded by developers creating their own server or those
who simply want to use the library of routines it provides.
##### libircd can be embedded in your application with very minimal overhead.
Linking to libircd from your executable allows you to customize and extend the
functionality of the server and have control over its execution, or, simply use
library routines provided by the library without any daemonization.
##### libircd runs only one server at a time.
Keeping with the spirit of simplicity of the original architecture, `libircd`
continues to be a "singleton" object which uses globals and keeps actual server
state in the library itself. In other words, **only one IRC daemon can exist
within a process's address space at a time.** Whether or not this was a pitfall
of the original design, it has emerged over the decades as a very profitable
decision for making IRCd an accessible open source internet project.
##### libircd is single-threaded✝
This methodology ensures there is an _uninterrupted_, _uncontended_,
_predictable_, execution. If there are periods of execution which are
computationally intense like parsing, hashing, cryptography, etc: this is
absorbed in lieu of thread synchronization and bus contention. Scaling this
system is done through running multiple independent instances which
synchronize with application logic.
✝ However, don't start assuming a truly threadless execution for the entire
address space. If there is ever a long-running background computation or a call
to a 3rd party library which will do IO and block the event loop, we may use an
additional `std::thread` to "offload" such an operation. Thus we do have
a threading model, but it is heterogeneous.
##### libircd introduces userspace threading✝
IRCd presents an interface introducing stackful coroutines, a.k.a. userspace
context switching, a.k.a. green threads, a.k.a. fibers. The library avoids callbacks
as the way to break up execution when waiting for events. Instead, we harken back
to the simple old ways of synchronous programming where control flow and data are
easy to follow.
✝ If there are certain cases where we don't want a stack to linger which may
jeopardize the c10k'ness of the daemon the asynchronous pattern is still used.
##### libircd leverages formal grammars
We utilize the `boost::spirit` system of parsing and printing through formal grammars,
rather than writing our own parsers manually. In addition, we build several tools
on top of such formal devices like a type-safe format string library acting as a
drop-in for `::sprintf()`, but accepting objects like `std::string` without `.c_str()`
and prevention of outputting unprintable/unwanted characters that may have been
injected into the system somewhere prior.
### Overview
`libircd` is designed specifically as a shared object library. The purpose of its