GNOME Bugzilla – Bug 732097
nmcli: edit mode operating with second thread causes threading issue, and readline blocks mainloop
Last modified: 2020-11-12 14:29:08 UTC
there are two (related) issues in nmcli. 1.) in edit mode, nmcli will start a second thread and access libnm-util objects from that other thread without proper thread synchronization. This can cause race conditions and can easily lead to nmcli doing the wrong thing. It is not easy to operate libnm-util in a multithreadded way, so a much better solution is not to start a second thread and to work entirely on the glib mainloop. 2.) whenever reading from command line, nmcli blocks. In edit more it blocks the second thread (see problem 1.). In questionnaire mode, it blocks the glib main loop which can lead to subtle bugs. nmcli must not block the main loop, but instead return to the main loop and only read from command line when notified that there is something to read. This also means, that nmcli must expect that while waiting on user input (readline), the "world" might change in the meantime.
It *is* possible to make the multiple-threads thing work, as long as you do all the NM calls from the original thread, and use the extra thread to call readline(), not the other way around. (nmtui used to do basically this, with NM running in the main thread and newt running the UI in the second thread.) But it looks like (2) can be fixed by using rl_event_hook, and calling g_main_context_iteration() from there, and that might also provide a way of fixing (1).
(In reply to comment #1) > It *is* possible to make the multiple-threads thing work, as long as you do all > the NM calls from the original thread, and use the extra thread to call > readline(), not the other way around. (nmtui used to do basically this, with NM > running in the main thread and newt running the UI in the second thread.) Hm, you certainly cannot access any object that is owned by libnm-util without synchronizing with the main-loop (i.e. blocking). I guess, the glib main loop has a way to allow synchronizing with the main loop. But you still have to release the main loop when waiting for readline()... and you must be careful not to have any stale data when synchronizing anew after returning from readline(). I think this qualifies as "not easy" and not elegant. You say "used to". How does nmtui do it now? Seems like that the same approach would fit for both tui and cli. Variable: rl_hook_func_t * rl_event_hook If non-zero, this is the address of a function to call periodically when Readline is waiting for terminal input. By default, this will be called at most ten times a second if there is no keyboard input. rl_event_hook it invoke the function "from time to time" while being blocked. That seems ugly solution. Also, you must be careful if you call readline "recursively" (or make sure that it cannot happen).
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).