Discussion:
Busy loop in the wl_priv_signal_final_emit
Matteo Valdina
2018-08-29 21:46:12 UTC
Permalink
Hi,
I'm moving my compositor to latest libweston 5.0 /wayland 1.16 library and
I noticed a regression when I terminate my compositor.

The compositor will never exit because is stuck in a busy loop.
The busy loop is in the "wl_priv_signal_final_emit" that was added in the
latest wayland.

And precisely is looping to notify that the same client is disconnected.
With this code (from here:
https://github.com/wayland-project/wayland/blame/bb1a8ca91e7d99f54b43ece01674ccbd720ec4bd/src/wayland-server.c#L2057
)

while (!wl_list_empty(&signal->listener_list)) {
pos = signal->listener_list.next;
l = wl_container_of(pos, l, link);
wl_list_remove(pos);
wl_list_init(pos);
l->notify(l, data);
}

The listener_list is pointing to itself

$3 = {listener_list = {prev = 0x24f7eb0, next = 0x24f7eb0}, emit_list =
{prev = 0x298f888, next = 0x298f888}}
But to be empty next should point to &listener_list that it is
p &$3->listener_list
$11 = (struct wl_list *) 0x298f878


A more expert eye on this codebase can confirm that there is no issue on
how the wl_list_remove is done in wl_priv_signal_final_emit?

Best
Matteo Valdina
--
“There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way is
to make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.”
- Tony Hoare
Matteo Valdina
2018-08-30 15:39:43 UTC
Permalink
Hi,
I figure it out. The issue was in my compositor.
For reference, I was using the same wl_listener for multiple clients
(wl_client_add_destroy_listener). This was the root cause of my issue.

Best
Matteo
Post by Matteo Valdina
Hi,
I'm moving my compositor to latest libweston 5.0 /wayland 1.16 library and
I noticed a regression when I terminate my compositor.
The compositor will never exit because is stuck in a busy loop.
The busy loop is in the "wl_priv_signal_final_emit" that was added in the
latest wayland.
And precisely is looping to notify that the same client is disconnected.
https://github.com/wayland-project/wayland/blame/bb1a8ca91e7d99f54b43ece01674ccbd720ec4bd/src/wayland-server.c#L2057
)
while (!wl_list_empty(&signal->listener_list)) {
pos = signal->listener_list.next;
l = wl_container_of(pos, l, link);
wl_list_remove(pos);
wl_list_init(pos);
l->notify(l, data);
}
The listener_list is pointing to itself
$3 = {listener_list = {prev = 0x24f7eb0, next = 0x24f7eb0}, emit_list =
{prev = 0x298f888, next = 0x298f888}}
But to be empty next should point to &listener_list that it is
p &$3->listener_list
$11 = (struct wl_list *) 0x298f878
A more expert eye on this codebase can confirm that there is no issue on
how the wl_list_remove is done in wl_priv_signal_final_emit?
Best
Matteo Valdina
--
“There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way is
to make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.”
- Tony Hoare
--
“There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way is
to make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.”
- Tony Hoare
Loading...