https://github.com/zevv/cpstest
https://github.com/zevv/cpstest
Last synced: 11 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/zevv/cpstest
- Owner: zevv
- Created: 2021-06-20T17:36:37.000Z (over 4 years ago)
- Default Branch: master
- Last Pushed: 2024-03-03T12:09:37.000Z (almost 2 years ago)
- Last Synced: 2025-02-10T00:43:38.892Z (about 1 year ago)
- Language: Nim
- Size: 102 KB
- Stars: 6
- Watchers: 4
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# CPS test
This is a test project to do some "real" work with CPS to see where CPS can
shine, or to find where it is still lacking.
It is growing into small library for doing nice things with async CPS, providing
basic event queue handling, I/O primitives and network protocols.
## Results so far
### The good
- CPS is fun! I'm having a blast - with a few lines of code I move continations
to run on a different thread, for example for DNS resolving. See `dial()` in
`conn.nim`
- The quality of the CPS transformation is getting better by the day. For
day-to-day code I have not ran into big surprises, and any issues I did find
were often fixed within hours by the CPS authors.
- CPS in it's current state offers a nice and usable API; it allows for a very
natural "thread like" feel, writing linear code and hiding all the gory async
details to CPS.
- Performance of CPS is pretty good, the bottlenecks in this application are
mostly caused by me being lazy with memory allocations and string handling,
not by CPS.
- I like how the CPS continuation type can be used to silently carry state
through the code without having to explicitly pass that around: in this case
the event queue instance is part of the continuation type, and allows all cps
code to do seamless I/O or timer handling.
### The bad
- Stack traces in CPS result in the "real" trace, typically from main() into
the event() queue into the current continuation leg. From a users perpsective
it would be nice if the trace could unwind over the cps 'mom' stack to give a
better idea of "how I got there".
- Generics would come handy - I've been told these are to be expected shortly.
- At this time there is no way to create CPS "function pointers" or "closures",
which makes it harder to compose with CPS and do things like callback
functions or vtables. Given the nature of CPS I'm not sure if something like
this would be feasible though.
- Compilation times: CPS compilation is becoming a bit slow. Not a show stopper
for me yet.
### The ugly
- CPS and for loops don't play well - this is mostly a limitation of the Nim
macro system.
## Contents
This project consists of the following parts:
- types.nim: Shared types, including the basic continuation type
- evq.nim: The core event queue for suspending continuations on I/O or timers
- conn.nim: Low level CPS async socket handling: `dial()`, `bind()`, `send()`, `recv(), `close()`
- bconn.nim: Async CPS bufferd I/O layer on top of conn. `readLine()` and friends
- http.nim: Shared http code for reading and writing http requests and responses
- httpclient.nim: Basic HTTP client
- httpserver.nim: Basic HTTP server
- main.nim: main application
## Running
nim r --gc:arc main.nim