2a9da36c90
Note: need to probably address this in writeChannelNonblocking, as well. I don't fully understand what's going on here, but my intuition is that somehow the combination of `forever` and `writeChannel` wasn't tail recursive, and so stack space was being built-up. By registering the writer with the scheduler, and letting the stack unwind (I think...), this seems to fix the issue. |
||
|---|---|---|
| app | ||
| docs | ||
| src | ||
| .gitignore | ||
| CODE_OF_CONDUCT.md | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| Setup.hs | ||
| build-docs.sh | ||
| deli.cabal | ||
| stack.yaml | ||
README.md
deli
What is Deli?
Deli is a performance modeling tool, allowing you to understand and experiment with new designs at several orders of magnitude faster than wall-clock time. Specifically, Deli is designed to help you understand how long it takes for 'jobs' or 'requests' to complete in your system. Deli borrows concepts and terminology from queueing theory, and is implemented as a Haskell DSL, exposing a Go (language) -like concurrency and message-passing API.
Deli's documentation is divided into the following three sections, depending on your interest.
First time readers
If you're looking for an overview on Deli, and whether it may be appropriate for your problem, head over to our overview documentation.
Using Deli
If you've decided you want to use Deli, or are already using it in a project, then our user guide is a great resource.
Contributing
If you'd like to contribute to Deli, start with our contributing documentation.
License
Deli is BSD3 licensed. More information is availabile in LICENSE.