From: Boram Park <boram1288.park@samsung.com>
Date: Sun, 15 Oct 2017 10:02:57 +0000 (+0900)
Subject: ecore_glib: marking active only if there are events to handle
X-Git-Tag: accepted/tizen/unified/20171025.075203~14
X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=refs%2Fchanges%2F12%2F155612%2F6;p=platform%2Fupstream%2Fefl.git

ecore_glib: marking active only if there are events to handle

If select() returns 0, we expact rfds doesn't contains any fds. But even if
select() returns 0, rfds sometimes contains a wayland fd. It makes wrong
behavior.

Once exit from select(), _ecore_main_awake_handler_call() should be called here
to call wl_display_cancel_read() or wl_display_read_events().
If not, deadlock can occur when g_main_context_dispatch calls a user callback
and a user callback calls wl_display_roundtrip which make read_count +2 in one
thread. Moreover, if the main thread sleeps to wait for the some events in
g_main_context_dispatch() or _ecore_idle_enterer_call() function, and if another
thread calls prepare_read(), deadlock also can occur in main thread because main
thread has slept to wait for something and it can't call read_event() or
cancel_event().

Change-Id: Ia786ba2b7c525611be7d0ab9036581e812ce3a2f
---

diff --git a/src/lib/ecore/ecore_glib.c b/src/lib/ecore/ecore_glib.c
index b52c032..5535904 100644
--- a/src/lib/ecore/ecore_glib.c
+++ b/src/lib/ecore/ecore_glib.c
@@ -168,7 +168,22 @@ _ecore_glib_select__locked(GMainContext   *ctx,
    maxfds = (ecore_fds >= glib_fds) ? ecore_fds : glib_fds;
    ret = _ecore_glib_select_original(maxfds, rfds, wfds, efds, timeout);
 
-   _ecore_main_fdh_mark_active(rfds, wfds, efds);
+   /* If select() returns 0, we expact rfds doesn't contains any fds. But even if
+    * select() returns 0, rfds sometimes contains a wayland fd. It makes wrong
+    * behavior.
+    */
+   if (ret > 0)
+     _ecore_main_fdh_mark_active(rfds, wfds, efds);
+
+   /* Once exit from select(), _ecore_main_awake_handler_call() should be called here
+    * to call wl_display_cancel_read() or wl_display_read_events().
+    * If not, deadlock can occur when g_main_context_dispatch calls a user callback
+    * and a user callback calls wl_display_roundtrip which make read_count +2 in one
+    * thread. Moreover, if the main thread sleeps to wait for the some events in
+    * g_main_context_dispatch() or _ecore_idle_enterer_call() function, and if another
+    * thread calls prepare_read(), deadlock also can occur in main thread because main
+    * thread sleeps and it can't call read_event() or cancel_event().
+    */
    _ecore_main_awake_handler_call();
 
    ret = _ecore_glib_context_poll_to