[01:06:56] *** Quits: Horwitz (~mich1@p200300ec9f01b100022268fffe64e7c4.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) [01:19:57] *** Joins: Horwitz (~mich1@p200300ec9f021500022268fffe64e7c4.dip0.t-ipconnect.de) [01:19:57] *** ChanServ sets mode: +o Horwitz [06:55:26] *** Joins: Cyker (~Cyker@host-92-28-105-138.as13285.net) [10:12:31] *** Quits: Celelibi (celelibi@82-64-105-152.subs.proxad.net) (Remote host closed the connection) [10:22:59] *** Joins: Celelibi (celelibi@2a01:e0a:587:56f0:215:afff:fe49:d5cd) [17:05:49] *** Quits: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt) (Ping timeout: 260 seconds) [17:18:05] *** Joins: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt) [19:41:53] hi all, question on the event system (event.c): is adding/removing events thread-safe in all implementations? [19:42:03] It seems to be in event_glib.c (based on the glib docs at https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-timeout-add) [19:42:08] but every graphics driver seems to come with its own implementation [19:42:55] background: traff_http will need to do the http requests in a separate thread, to avoid locking up the UI [19:43:49] but result processing needs to happen on the main thread, which I would implement by adding a timeout event with a (near) zero timeout from the http thread [19:44:29] so does every implementation implement proper locking of all data structures, or do I need to do something? [20:16:32] graphics_android also relies on a thread-safe implementation, as far as I can tell [20:27:30] graphics_null simply does nothing, hence thread-safe (except for the debug output), however, callbacks will never run [20:28:23] which leaves us with qt5, win32, sdl, opengl, qt_qpainter and cocoa [20:45:50] on win32, add_watch does nothing, add_timeout does not look thread-safe, and add_idle just calls add_timeout... so this will need a write lock around it [21:20:27] graphics_opengl does nothing except for debug output, just like graphics_null [21:25:40] cocoa: no idea, some iOS stuff that I'm not really familiar with [21:29:07] qt_qpainter: event system depends on conditionals, the built-in one uses stuff that does not look thread-safe as far as I can tell [21:30:23] qt5 doesn't look thread-safe either [21:46:53] SDL: can't tell for sure [21:47:44] conclusion: some implementations are thin translation layers to libraries which are thread safe [21:47:55] others are simply NOP [21:48:50] others I can't tell for sure, some of them need some more complex logic [21:50:12] glib, android, null and opengl look thread-safe to me [21:51:37] win32, qt_qpainter and qt5 don't look thread-safe, we'd need to implement write locks for the respective methods [21:52:13] as for cocoa and SDL, I can't tell for sure [22:27:27] *** Quits: owlman (~owlman@203.221.238.93) (Ping timeout: 246 seconds) [22:27:36] *** Joins: owler (~owlman@124-169-55-216.dyn.iinet.net.au)