Signal support

[grimnight]

For example i3blocks supports multiple signals which you can trigger using pkill -SIGRTMIN+10 i3blocks, which then causes an action.

Could you add atleast two signals, one for re-reading INPUT file and another for writing OUTPUT file.
This would open ffs for uses in scripts and would allow updating INPUT and/or OUTPUT files without needing to restart ffs.

[mgree]

This is an interesting idea---thanks for making the issue!

I'd been thinking about fully "live" execution using some kind of inotify API. This signal mechanism could largely use the same code, with only a slightly different mechanism.

There are some technical challenges here: at present, mounting with FUSE gives up program control: we just get FUSE requests until unmount, when we return to main. So if a signal handler sets some global "time to read/write" bit, we won't actually do anything until somebody makes a request. Running, e.g., fsync or ls would be enough to trigger it, but it's not ideal.

fuser has another API that spawns a thread for mounting; the main thread and the FUSE mount thread could share a lock on the FS itself. Then we could poll the signal bit, grab the lock, and update the FS (or write it out).

i3blocks seems popular... is following their protocol the most common thing? What should we do on macOS, where I don't believe SIGRTMIN exists?

[grimnight]

I have been enjoying using i3blocks, but I don't know if following their protocol would be the most common thing to do. After some research it would seem that SIGUSR1 and SIGUSR2 are available on mac so it might be better to use them instead of RTMIN..

[mgree]

In principle the signals could be configurable, though that's very fiddly. In the world where ffs eventually works on Windows, the signal approach won't work---I just learned that they have a very limited set of signals.

It'd be possible to use other IPC protocols. I suspect that listening on the loopback device would be the simplest thing. In fact, it would be easy to spin up a web-server that answered GraphQL queries (or somesuch) on the internal FS, and wrap that with something that writes the response JSON to disk.

In general, I'm starting to envision a notification/IPC mechanism with multiple ways in. Reading/writing out input/output seems like a good use case, and I can imagine metrics and partial read/writes.

I don't know what the schedule for this would be. My next stop was comparing with an eager, plain-FS based approach (#52), with some benchmarking (#9). I'd be happy to look at a PR for features here, but I'd want to make sure we designed any IPC mechanism with the right abstraction from day 1.