Some negatives with the current approach (evented FS watcher)
Build loops are possible
If you forget to ignore something, its possible to get stuck in a
build loop, where the command outputs a file, which triggers a
rebuild, which outputs a file, which triggers...
CPU usage
Evented watchers aren't free. Larger the project, the more %CPU it
takes to just watch the FS
Wasted work
After everysave, a build is triggered - which isn't ideal as in most
cases one will save more than 1 file before tabbing over to the
browser. This leads to more wasted CPU spent rerunning commands on
every save.
-> Request comes in
-> Pause Proxy
-> Check for FS changes
-> If changes exist, rebuild
-> Unpause Proxy
This has several advantages:
0% CPU usage while idle
No wasted builds
The obvious downside is that now each request needs to check the FS for
changes.
However, with these changes it is possible to chain multiple tychus's
together. When using that feature, a --wait flag has been added. Using
that flag will tell tychus to block until the user specified command
finishes. This command will most often be some script or quick series of
commands and not something blocking like a webserver.
PatKoperwas
commented
6 years ago
Some negatives with the current approach (evented FS watcher)
Build loops are possible If you forget to ignore something, its possible to get stuck in a build loop, where the command outputs a file, which triggers a rebuild, which outputs a file, which triggers...
CPU usage Evented watchers aren't free. Larger the project, the more %CPU it takes to just watch the FS
Wasted work After everysave, a build is triggered - which isn't ideal as in most cases one will save more than 1 file before tabbing over to the browser. This leads to more wasted CPU spent rerunning commands on every save.
New approach: Check FS on HTTP request.
Flipped the sequence. Previously: -> FS Change -> Pause Proxy -> Rebuild -> Unpause Proxy
New sequence:
-> Request comes in -> Pause Proxy -> Check for FS changes -> If changes exist, rebuild -> Unpause Proxy
This has several advantages:
The obvious downside is that now each request needs to check the FS for changes.
However, with these changes it is possible to chain multiple
tychus's together. When using that feature, a--waitflag has been added. Using that flag will tell tychus to block until the user specified command finishes. This command will most often be some script or quick series of commands and not something blocking like a webserver.