Our next indication of the delta editor's flexibility came when we needed to do two or more distinct things in the same tree edit. One of the earliest such situations was the need to handle cancellations. When the user interrupted an update, a signal handler trapped the request and set a flag; then at various points during the operation, we checked the flag and exited cleanly if it was set. It turned out that in most cases, the safest place to exit the operation was simply the next entry or exit boundary of an editor function call. This was trivially true for operations that performed no I/O on the client side (such as change summarizations and diffs), but it was also true of many operations that did touch files. After all, most of the work in an update is simply writing out the data, and even if the user interrupts the overall update, it usually still makes sense to either finish writing or cleanly cancel whatever file was in progress when the interrupt was detected.
But where to implement the flag checks? We could hardcode them
into the delta editor, the one returned (by reference) from Get_Update_Editor(). But that's obviously a
poor choice: the delta editor is a library function that might be called
from code that wants a totally different style of cancellation checking,
or none at all.
A slightly better solution would be to pass a
cancellation-checking callback function and associated baton to Get_Update_Editor(). The returned editor would periodically ...
No credit card required