If it were me, I'd try for a single process with the UI and the indexer running in separate threads. Communication between threads could be as simple as global

If it were me, I'd try for a single process with the UI and the indexer running in separate threads. Communication between threads could be as simple as global variables + a mutex lock. Two problems to solve: - Communication from UI thread to backend thread - Communication from backend thread to UI thread For communicating to the backend thread, I like using event flags but other people like using mailboxes. Both work. With event flags, you set a bit (for instance, backend_thread.start = True) and if the backend thread is sleeping, it gets woken up by the OS scheduler. UI frameworks often provide a function to run your code in the UI thread, so your indexer could use that to periodically update the UI. For example you could have an Update() function that reads the global variables defining the state of the indexer and updates every UI element to match, and then the indexer periodically schedules Update to run on the main thread when it's doing its work. In my work there's typically a state machine that coordinates UI + backend. It might start with state = BACKEND_STOPPED. Then when you press the start button, transitions to state = BACKEND_RUNNING and notifies the backend thread using an event flag. When the backend thread finishes, it can transition back to BACKEND_STOPPED and schedule an update to the UI. ---- Another pattern I've seen is using the database for communication. You might have a "jobs" table in sqlite with indexing jobs to perform. The front-end adds "jobs" to the table and notifies the backend thread to wake up. The back-end processes jobs and updates their status and notifies the UI thread when the status changes.