You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great to refactor this code to not be so horrible.
One of the main problems I had is that there are some types that can't easily be passed between threads, including handles for connecting to Google Calendar, and connection handles for X. Ideally, the code that handles both of these tasks would have their own threads.
I'm not sure the best solution to all these problems, but I was thinking that instead of using threads and channels for concurrency and communication, it would be easier to use some sort of service-oriented actor model, where each state machine would be it's own actor, as well as the parts of the code that can't be passed between threads.
Testing and simplifying all of the state-transitions would also be very helpful. There are probably some state transitions that don't make any sense, yet are still possible in the current code.
The text was updated successfully, but these errors were encountered:
Some of the break-time code is really horrible. There are a mess of thread-based state machines, all communicating over mpsc channels.
Here are the main state machines:
break-time/src/scheduler/idle_detector.rs
Lines 47 to 100 in 6bad134
break-time/src/scheduler.rs
Lines 141 to 254 in 6bad134
break-time/src/lib.rs
Lines 31 to 67 in 6bad134
It would be great to refactor this code to not be so horrible.
One of the main problems I had is that there are some types that can't easily be passed between threads, including handles for connecting to Google Calendar, and connection handles for X. Ideally, the code that handles both of these tasks would have their own threads.
I'm not sure the best solution to all these problems, but I was thinking that instead of using threads and channels for concurrency and communication, it would be easier to use some sort of service-oriented actor model, where each state machine would be it's own actor, as well as the parts of the code that can't be passed between threads.
Testing and simplifying all of the state-transitions would also be very helpful. There are probably some state transitions that don't make any sense, yet are still possible in the current code.
The text was updated successfully, but these errors were encountered: