As explained in #1732, there are some concurrency issues in polybar and this issue is a try to address this problem. Nothing is set in stone, feels free to give your opinion! 😃

At the moment a lot of threads could be removed (more or less easily) and removing these threads could be a way to address some concurrency issues. That's why I propose to rework the main loop.

The mainloop should look like this (pseudo-code):

while (!stop)
  dispatch_input_events();
  update_modules();
  if (dirty)
      build_output();
      redraw();
  sleep_until_next_update_is_needed();

• The collect_and_dispatch_input_events() should collect the input events (click, scroll, …), resolves the targets and transmits the events. When a module gets an event, it is added into a queue of event to process.
• The update_modules function calls the update method of each module, and causes the module to update it internal state (the labels).
• The redraw function simply redraw the bar.
• The sleep_until_next_update_is_needed() sleep until an event has been receive by a module or by the controller for the input events. In case there is no event, the controller sleep until the next required update (internal property of each module).

In this architecture each module still need to gets the other events by themselves.
When an event is receive by a module, the event can be ignored but should not modify the internal state, the event is then stored into a queue that will be processed during the update. The only variable that should be modified is a flag signaling that the module should be updated. Why a flag and not an event to the controller -> for the separation in multiple SO files and the plugin system.

Also, the build and update mutexes should be merged into one, since in the current architecture they should be locked at the same time almost every time (this is impossible now because some modules wait into their has_event() method). The scope of the should be as "small" as possible. At the moment, some mutexes are locked while no sensible data are accessed or even during a sleep !!! (See the method poll_events in inotify_module.hpp)

I tried to keep in mind that we also aim to separate every modules in several SO files but if I missed something please let me know. :)

If something is unclear, feel free to ask.
I will try to implement a dummy prototype this week-end.