forked from cadey/xesite
blog/olin 1: update based on feedback
This commit is contained in:
parent
c2c2b486a6
commit
ec67d0eb41
|
@ -5,7 +5,7 @@ date: 2018-09-01
|
||||||
|
|
||||||
# [Olin][olin]: 1: Why
|
# [Olin][olin]: 1: Why
|
||||||
|
|
||||||
[Olin][olin] is an attempt at defining a radically new primitive to make it
|
[Olin][olin] is an attempt at defining a radically new operating primitive to make it
|
||||||
easier to reason about, deploy and operate event-driven services that are
|
easier to reason about, deploy and operate event-driven services that are
|
||||||
independent of the OS or CPU of the computer they are running on. It will have
|
independent of the OS or CPU of the computer they are running on. It will have
|
||||||
components that take care of the message queue offsetting, retry logic,
|
components that take care of the message queue offsetting, retry logic,
|
||||||
|
@ -26,12 +26,14 @@ message UserLoginEvent {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
and when matching data is written to the queue for the event type `example.UserLoginEvent`,
|
When matching data is written to the queue for the event type `example.UserLoginEvent`,
|
||||||
all of the handlers registered to that data type will run with serialized protocol
|
all of the handlers registered to that data type will run with serialized protocol
|
||||||
buffer bytes as its standard input. If the handlers return a nonzero exit status,
|
buffer bytes as its standard input. If the handlers return a nonzero exit status,
|
||||||
they are retried up to three times, exponentially backing off.
|
they are retried up to three times, exponentially backing off.
|
||||||
Handlers need to deal with the fact they can be run out of order.
|
Handlers need to deal with the fact they can be run out of order.
|
||||||
|
|
||||||
|
Consider an Olin handler equivalent to a Unix process.
|
||||||
|
|
||||||
## Background
|
## Background
|
||||||
|
|
||||||
Very frequently, I end up needing to write applications that basically end up
|
Very frequently, I end up needing to write applications that basically end up
|
||||||
|
@ -79,6 +81,17 @@ random readers, everything is done via filesystem system calls.
|
||||||
Consider this the first draft of Dagger, everything here is subject to change.
|
Consider this the first draft of Dagger, everything here is subject to change.
|
||||||
This is going to be the experimental phase.
|
This is going to be the experimental phase.
|
||||||
|
|
||||||
|
Consider Dagger at the level _below_ libc in most Linux environements. Dagger
|
||||||
|
is the kind of API that libc would be implemented on top of.
|
||||||
|
|
||||||
|
### VM
|
||||||
|
|
||||||
|
Dagger processes will use [WebAssembly][wasm] as a platform-independent virtual
|
||||||
|
machine format. WebAssembly is used here due to the large number of
|
||||||
|
implemetnations and compilers targeting it for the use in web programming. We can
|
||||||
|
also benefit from the amazing work that has gone into the use of WebAssembly in
|
||||||
|
front-end browser programming without having to need a browser!
|
||||||
|
|
||||||
### Base Environment
|
### Base Environment
|
||||||
|
|
||||||
When a dagger process is opened, the following files are open:
|
When a dagger process is opened, the following files are open:
|
||||||
|
@ -87,9 +100,6 @@ When a dagger process is opened, the following files are open:
|
||||||
- 1: standard output: the standard output of the program.
|
- 1: standard output: the standard output of the program.
|
||||||
- 2: standard error: error output for the program.
|
- 2: standard error: error output for the program.
|
||||||
|
|
||||||
Any memory address above byte 4096 is free for implementing applications to use.
|
|
||||||
Memory addresses below byte 4096 are reserved for future internal-only use.
|
|
||||||
|
|
||||||
### File Handlers
|
### File Handlers
|
||||||
|
|
||||||
In the open call (defined later), a file URL is specified instead of a file name.
|
In the open call (defined later), a file URL is specified instead of a file name.
|
||||||
|
@ -110,6 +120,10 @@ I'd like to add the following handlers in the future:
|
||||||
- rand - cryptographically secure random data good for use in crypto keys `rand://`
|
- rand - cryptographically secure random data good for use in crypto keys `rand://`
|
||||||
- time - unix timestamp in a little-endian encoded int64 on every read() - `time://utc`
|
- time - unix timestamp in a little-endian encoded int64 on every read() - `time://utc`
|
||||||
|
|
||||||
|
In the future, users should be able to define arbitrary other protocol handlers
|
||||||
|
with custom webassembly modules. More information about this feature will be
|
||||||
|
posted if we choose to do this.
|
||||||
|
|
||||||
### Handler Function
|
### Handler Function
|
||||||
|
|
||||||
Each Dagger module can only handle one data type. This is intentional. This
|
Each Dagger module can only handle one data type. This is intentional. This
|
||||||
|
@ -128,9 +142,11 @@ In clang in C mode, you could define the entrypoint for a handler module like th
|
||||||
```c
|
```c
|
||||||
// handle_nothing.c
|
// handle_nothing.c
|
||||||
|
|
||||||
|
#include <dagger.h>
|
||||||
|
|
||||||
__attribute__ ((visibility ("default")))
|
__attribute__ ((visibility ("default")))
|
||||||
int handle() {
|
int handle() {
|
||||||
// read all of standard input to memory and handle it
|
// read standard input as necessary and handle it
|
||||||
return 0; // success
|
return 0; // success
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
@ -138,12 +154,15 @@ int handle() {
|
||||||
### System Calls
|
### System Calls
|
||||||
|
|
||||||
A [system call][syscall] is how computer programs interface with the outside
|
A [system call][syscall] is how computer programs interface with the outside
|
||||||
world. When a dagger program makes a system call, the amount of time the program
|
world. When a Dagger program makes a system call, the amount of time the program
|
||||||
spends waiting for that system call is collected and recorded based on what
|
spends waiting for that system call is collected and recorded based on what
|
||||||
underlying resource took care of the call. This means, in theory, users of olin
|
underlying resource took care of the call. This means, in theory, users of olin
|
||||||
could alert on HTTP requests from one service to another taking longer amounts
|
could alert on HTTP requests from one service to another taking longer amounts
|
||||||
of time very trivially.
|
of time very trivially.
|
||||||
|
|
||||||
|
Future mechanisms will allow for introspection and checking the status of
|
||||||
|
handlers, as well as arbitrarily killing handlers that get stuck in a weird way.
|
||||||
|
|
||||||
Dagger uses the following system calls:
|
Dagger uses the following system calls:
|
||||||
|
|
||||||
- open
|
- open
|
||||||
|
@ -265,3 +284,4 @@ a very long-term project that radically redesigns how software should be written
|
||||||
[olin]: https://github.com/Xe/olin
|
[olin]: https://github.com/Xe/olin
|
||||||
[goslack]: https://invite.slack.golangbridge.org
|
[goslack]: https://invite.slack.golangbridge.org
|
||||||
[wasmgo]: https://github.com/Xe/olin/tree/master/internal/abi/wasmgo
|
[wasmgo]: https://github.com/Xe/olin/tree/master/internal/abi/wasmgo
|
||||||
|
[wasm]: https://webassembly.org
|
||||||
|
|
Loading…
Reference in New Issue