race condition with messages to/from weston-launch
We ran into an intermittent issue where weston will encounter an error if we switch the virtual terminal too quickly. In analyzing the code, we realized that there is a race condition inherent with the current design.
The race condition occurs when weston sends the
WESTON_LAUNCHER_OPEN message to weston-launch and receives the corresponding
fd handle value. The
WESTON_LAUNCHER_OPEN message would have been triggered by the
WESTON_LAUNCHER_ACTIVATE message sent from weston-launch. The problem is that if weston-launch receives a
VT_RELEASE signal from the kernel before it receives the
WESTON_LAUNCHER_OPEN message from weston, then weston-launch will send the
WESTON_LAUNCHER_DEACTIVATE message when weston is going to be expecting the
fd handle value next.
The inherent problem here is that both weston-launch and weston can asynchronously send messages at any point in time, but weston expects that after sending WESTON_LAUNCHER_OPEN, that weston-launch will always respond with the fd handle value reply.
One solution would be to open 2 sockets pairs and use one for asynchronous message initiated by each endpoint. Another solution would be to reserve a msg id for the WESTON_LAUNCHER_OPEN reply and modify weston to receive it asynchronously somehow.