After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 694274 - wayland: don't attempt to unqueue events when events are paused
wayland: don't attempt to unqueue events when events are paused
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-02-20 14:53 UTC by Thomas Wood
Modified: 2014-02-14 00:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wayland: don't attempt to unqueue events when events are paused (1.21 KB, patch)
2013-02-20 14:53 UTC, Thomas Wood
committed Details | Review
Broadway/Quartz/Win32: make event source prepare()/check() note paused status (4.23 KB, patch)
2013-02-20 17:56 UTC, Owen Taylor
committed Details | Review

Description Thomas Wood 2013-02-20 14:53:09 UTC
gdk_display_get_event will return NULL when events are paused and therefore
no events can be processed.
Comment 1 Thomas Wood 2013-02-20 14:53:11 UTC
Created attachment 236938 [details] [review]
wayland: don't attempt to unqueue events when events are paused
Comment 2 Rob Bradford 2013-02-20 16:52:49 UTC
Review of attachment 236938 [details] [review]:

LGTM, can we have a bit more explanation in the commit message ?
Comment 3 Rob Bradford 2013-02-20 16:52:49 UTC
Review of attachment 236938 [details] [review]:

LGTM, can we have a bit more explanation in the commit message ?
Comment 4 Owen Taylor 2013-02-20 17:56:55 UTC
Created attachment 236961 [details] [review]
Broadway/Quartz/Win32: make event source prepare()/check() note paused status

Here's a patch for the rest of the backends, feel free to squash it in and
steal the text from the commit message for a detailed explanation.
Comment 5 Kristian Høgsberg 2013-02-20 19:35:20 UTC
(In reply to comment #1)
> Created an attachment (id=236938) [details] [review]
> wayland: don't attempt to unqueue events when events are paused

Fixes the lock-ups I was seeing.

Tested-by: Kristian Høgsberg <krh@bitplanet.net>
Comment 6 Matthias Clasen 2013-02-20 23:52:35 UTC
Review of attachment 236961 [details] [review]:

looks fine to me
Comment 7 Owen Taylor 2013-02-21 15:01:42 UTC
I didn't squash the two patches - but I duplicated the explanatory text from
my commit to the Wayland commit.

Attachment 236938 [details] pushed as 00a107c - wayland: don't attempt to unqueue events when events are paused
Attachment 236961 [details] pushed as df3e19b - Broadway/Quartz/Win32: make event source prepare()/check() note paused status
Comment 8 John Ralls 2013-02-28 20:06:31 UTC
df3e19b breaks the build in quartz:
gdkeventloop-quartz.c: In function 'gdk_event_prepare':
gdkeventloop-quartz.c:623: error: 'display' undeclared (first use in this function)
gdkeventloop-quartz.c:623: error: (Each undeclared identifier is reported only once
gdkeventloop-quartz.c:623: error: for each function it appears in.)
gdkeventloop-quartz.c: In function 'gdk_event_check':
gdkeventloop-quartz.c:641: error: 'display' undeclared (first use in this function)
Comment 9 Owen Taylor 2013-02-28 20:07:46 UTC
A patch and testing would be much appreciated! :-) I can keep on making changes to the code, but...
Comment 10 John Ralls 2013-02-28 20:40:02 UTC
The fix is obvious from the surrounding code: _gdk_display instead of display, and #include <gdk/gdkdisplayprivate.h> is required.

I've fixed it for you, afe8ce2.
Comment 11 Fan, Chun-wei 2013-03-06 10:17:26 UTC
The (In reply to comment #10)
> The fix is obvious from the surrounding code: _gdk_display instead of display,
> and #include <gdk/gdkdisplayprivate.h> is required.
> 
> I've fixed it for you, afe8ce2.

The same also happened to the Win32 backend-I proposed a patch, which seems to be similar in approach to John's patch to bug 694339.  Can I ask someone to give a quick look at that (and the other patches there) too?

With blessings, thank you!
Comment 12 Allison Karlitskaya (desrt) 2014-02-14 00:56:05 UTC
I think there is still a bug here.

Returning FALSE from check/prepare() will prevent events from being dispatched, but since the pollfd is still registered with the mainloop, we're going to spin (since poll() will return immediately due to available IO).