Outcurses: Difference between revisions
| Line 245: | Line 245: | ||
<ul> | <ul> | ||
<li>processing the <tt>RTM_DELLINK</tt> to extract the interface index</li> | <li>processing the <tt>RTM_DELLINK</tt> to extract the interface index</li> | ||
<li>acquiring the core lock</li> | <li>acquiring the core ifaces lock</li> | ||
<li>finding the | <li>finding the iface specified by this index</li> | ||
<li>removing the interface from the lookup structure</li> | <li>removing the interface from the lookup structure</li> | ||
<li>cancelling and joining the packet socket thread for this iface</li> | |||
<li>acquiring the UI lock (via <tt>interface_removed_callback</tt>)</li> | <li>acquiring the UI lock (via <tt>interface_removed_callback</tt>)</li> | ||
<li>removing the <tt>iface_state</tt> from its circular list of all ifaces</li> | <li>removing the <tt>iface_state</tt> from its circular list of all ifaces</li> | ||
| Line 257: | Line 258: | ||
</ul> | </ul> | ||
Not only is this a tremendous amount of (possibly blocking!) work done while holding *multiple* locks, but it is complicated for the application programmer (what goes away when?), difficult to reason about what needs to be copied into the UI's state (and this process does not self-recover if the two ever diverge), | Not only is this a tremendous amount of (possibly blocking!) work done while holding *multiple* locks, but it is complicated for the application programmer (what goes away when?), it is difficult to reason about what needs to be copied into the UI's state (and this process does not self-recover if the two ever diverge), and we waste memory and time with said copies. Can we not unlock the iface lock after splicing out the interface from its lookup structure? It would seem so, but verifying it would be more effort than I want to put in at the moment. Finally, I suspect it all to be broken. Who knows. This sucks. | ||
==Panel animations== | ==Panel animations== | ||