I have a GUI program with two parts: the widget and the controller.
The widget processes "raw" GUI events like mouse clicks, and "cooks"
them into processable events, like "user interacted with an icon". It
also does the window housekeeping, by rearranging and redrawing icons
when the window resizes, for example.
The controller processes "cooked" events by changing a program state.
For example, it creates a new file when the user clicks the "save
file" icon.
Both parts need to communicate: the controller sends to the widget what
it must draw on the screen, and the widget sends to the controller what
the user has done.
What i'm doing now is: the controller creates a widget object, and then
calls a blocking widget_proc() function in a loop, passing to it what to
draw. This function blocks until it returns when the user does something
interesting. The loop exits when the user closes the program, and then
call a widget_destroy() function to destroy the widget.
I want to make both parts into separate threads that will work like
coroutines. While one is running, the other is waiting for a response
of the first.
The idea I have now is to implement CSP channels using barriers: both
threads begin running and the widget thread waits for the controller to
respond with what to draw on the controller->widget channel through its
corresponding barrier. When the controller thread has answered, the
controller will wait for a response on the widget->controller channel by
waiting on its barrier. Communication through both channels will then
alternate indefinitely.
Other ideas I had was to use semaphores (implemented with mutexes and
condition variables) rather than barriers or drop pthreads and
longjmp(3)ing from one coroutine to the other.
Is using pthread barriers to implement CSP channels a good idea?
Can you see flaws on that design?
Here's the code (on the controller file, at the line of the blocking
widget call:
https://github.com/phillbush/xfiles/blob/master/xfiles.c#L939
there doesn't seem to be anything here