4 ms·
Yeah, this is amazing. It allows for a whole different aspect of troubleshooting (or maybe even fuzzing?). What happens if two different pieces of software have
by thaumaturgy 9y ago
Yeah, this is amazing. It allows for a whole different aspect of troubleshooting (or maybe even fuzzing?). What happens if two different pieces of software have to communicate but can't agree on the time? Is there an annoying caching bug that normally only gets triggered every few days?
- majke 9y ago(author here) That's the intention! Protocol development, protocol testing. Think - leap seconds. While we don't support having different timer for each process yet, this is easy to imagine. Also - this is somewhat similar to golang race detector in spirit - looking for explicit synchronizations. The general idea is that you should be able to run multiple processes within the thing, and that they should be able to just talk to each other freely. There are a number of "protocol simulators" out there, but I always found them academic. I wanted to build a tool that will allow me run and test and do code coverage of my code, without having to wait forever for timeouts and timers to kick in to test rare branches.
- glossbar 9y agoTry using it for consensus debugging. Like wrapping a few zookeeper or console processes with FC. Time is a fun one to debug, slips are not fun to debug in prod even though one thinks ntp is always reliable.