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 | <li>acquiring the core's iface lock</li> | ||
<li>finding the | <li>finding the <tt>interface</tt> specified by this index</li> | ||
<li>removing the interface from the lookup structure</li> | <li>removing the <tt>interface</tt> from the lookup structure</li> | ||
<li>cancelling | <li>acquiring the <tt>interface</tt>'s marshal lock</li> | ||
<li>acquiring the UI lock ( | <li>cancelling the packet socket thread for this <tt>interface</tt></li> | ||
<li>removing the <tt>iface_state</tt> from its circular list of all | <li>releasing the <tt>interface</tt>'s marshal lock</li> | ||
<li>removing the <tt>reelbox</tt> from its own circular list of visible | <li>joining the packet socket thread for this <tt>interface</tt></li> | ||
<li>acquiring the UI lock (start of <tt>interface_removed_callback</tt>)</li> | |||
<li>removing the <tt>iface_state</tt> from its circular list of all <tt>iface_state</tt>s</li> | |||
<li>removing the <tt>reelbox</tt> from its own circular list of visible <tt>reelbox</tt>en</li> | |||
<li>destroying the panel, reelbox, and iface_state</li> | <li>destroying the panel, reelbox, and iface_state</li> | ||
<li>repairing the screen by filling in this hole, possibly making other ifaces visible</li> | <li>repairing the screen by filling in this hole, possibly making other ifaces visible</li> | ||
<li>releasing the UI lock</li> | <li>releasing the UI lock</li> | ||
<li>destroying the interface</li> | <li>releasing the iface lock</li> | ||
<li>destroying the <tt>interface</tt></li> | |||
</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?), 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. | 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. That marshaling lock could probably be reduced to an atomic, as it's unattached to a condvar. 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, and I ought set myself on fire. | ||
For Outcurses and its general-purpose panelreels, we cannot assume deep application assistance. We cannot assume understanding of application internals. We cannot assume that it is possible to cache structure beyond the circular list of top-level objects corresponding to tablets, and we cannot even assume this last to be truly reflected in the application, which might very well not have a concept of ordering among the tablets. Furthermore, it would be a fine thing indeed to wholly decouple screen updates from any locked core code. | For Outcurses and its general-purpose panelreels, we cannot assume deep application assistance. We cannot assume understanding of application internals. We cannot assume that it is possible to cache structure beyond the circular list of top-level objects corresponding to tablets, and we cannot even assume this last to be truly reflected in the application, which might very well not have a concept of ordering among the tablets. Furthermore, it would be a fine thing indeed to wholly decouple screen updates from any locked core code. | ||