)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"change_message_id":"eff89dc98cef40074a80494c40d7b5c5f9b41b5d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d163c97d_6ae908f9","updated":"2025-11-16 12:45:52.000000000","message":"I do not understand anything of this :-( - so we should look at this together, and you explain to me what happens where...\n\nI did *test* it (t_client/t_server) and that part still works, so generally it\u0027s not introducing breakage ;-) - but to feel comfortable +2\u0027ing it, I need to understand it better.","commit_id":"0c317b79cfa7c42e1ac29c5340831ca6a415f68f"},{"author":{"_account_id":1000034,"name":"its_Giaan","display_name":"Gianmarco De Gregori","email":"gianmarco@mandelbit.com","username":"its_Giaan"},"change_message_id":"fbbbe026dc077e7d7fff28dcae47f2be16a0b729","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"65f42bdc_bd122b10","in_reply_to":"d163c97d_6ae908f9","updated":"2025-11-20 10:58:45.000000000","message":"We discussed this on IRC","commit_id":"0c317b79cfa7c42e1ac29c5340831ca6a415f68f"},{"author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"change_message_id":"148b738f0fdb8f0aedf7c03834044f9897edda8f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e1660176_0666a929","updated":"2025-11-21 21:03:37.000000000","message":"IRC notes...\n\n```\n18:10 \u003c@cron2\u003e okay\n18:10 \u003c@cron2\u003e - drop the #ifdef MULTI_DEBUG_EVENT_LOOP (completely)\n18:10 \u003c@cron2\u003e - add the comment :-)\n18:10 \u003c@cron2\u003e - drop FILE_CLOSED, plus explain in the commit message\n18:10 \u003c@cron2\u003e - drop the new msg() again, because, too excessive\n18:11 \u003c@cron2\u003e and someone needs to explain get_io_flags_dowork_udp() to me\n18:11 \u003c@cron2\u003e why is it called \"udp\" and the comment says \"for TCP \u0026 UDP \n               sockets\"?\n18:13 \u003c@cron2\u003e and why does it say \"Wait for I/O events\" when all it does (does \n               it?) is set up the flags for events we want to see?\n18:14 \u003c Giaan\u003e probably a copy paste from it´s ancestor (io_wait())\n18:15 \u003c@cron2\u003e should TUN_WRITE then also be removed from get_io_flags_udp()?\n18:15 \u003c Giaan\u003e no\n18:15 \u003c Giaan\u003e we need that for tun_set()\n18:17 \u003c@cron2\u003e do I even dare to ask how tun_set() and get_io_flags_udp() \n               relate, and why get_io_flags_udp() would deal with TUN_WRITE \n               while get_io_flags_dowork_udp() does not?\n18:17 \u003c Giaan\u003e ah indeed \n18:17  * cron2 has to leave, and fetch the kids from sports... so will be back \n          tomorrow and work on this...\n18:17 \u003c Giaan\u003e it´s related to the get_io_flags_dowork_udp()\n18:18 \u003c@cron2\u003e (can we get rid of get_io_flags_dowork_udp()?)\n18:18 \u003c@cron2\u003e just fold these two lines into the caller... this used to be \n               much larger\n18:18 \u003c Giaan\u003e yeah, and then all the udp sockets won´t work :D\n18:19 \u003c@cron2\u003e nah, keep the logic, but put it into get_io_flags_udp() instead \n               of having an extra function for just one extra function call + 1 \n               assignment :-)\n18:19 \u003c@cron2\u003e anyway, will be back...\n18:20 \u003c Giaan\u003e please dump all your concerns in gerrit so we won´t forget :-)\n```","commit_id":"2c2bb5c84570121c8ac5a90d083ac60e87a26777"}]}