If nhwindows_hangup() were to get called a second time, it would have
saved hup_exit_nhwindows() as the previous interface's shutdown routine.
Then if/when exit_nhwindows() gets called, hup_exit_nhwindows() would
have called itself with uncontrolled recursion. So guard against that by
preventing the hangup shutdown routine from ever being saved as previous
interface shutdown routine.
Also, avoid the exit_windows macro when using it as a pointer rather
than for a function call, since pre-ANSI compilers might be confused by
its expansion.
From two weeks ago:
> The last of my intended hangup overhaul. Once hangup is detected,
> replace currently loaded windowing routines with stubs that never do any
> terminal I/O. Real interface routines call their siblings directly rather
> than via the windowprocs pointers, so this shouldn't pull the rug out from
> under them, but it also can't prevent whatever they have in progress at
> the time of hangup from attempting further I/O once the handler returns.
hangup_nhwindows() shouldn't call exit_nhwindows() prior to replacing
windowprocs with no-ops. Even though the original intgerface can still
access its own routines directly, the exit_nhwindows() routine probably
releases its dynamic data structures. And those could be in active use if
the hangup occurs while an interface routine is executing.
The last of my intended hangup overhaul. Once hangup is detected,
replace currently loaded windowing routines with stubs that never do any
terminal I/O. Real interface routines call their siblings directly rather
than via the windowprocs pointers, so this shouldn't pull the rug out from
under them, but it also can't prevent whatever they have in progress at
the time of hangup from attempting further I/O once the handler returns.
[We might want to change nhwindows_hangup() into winprocs.hangup_nhwindows()
so that each interface has more control over its own fate.]
This assumes that user input of ESC and menu selection result of -1
everywhere in the core will eventually cause active function calls to
unwind their way back to moveloop() rather than to continually re-prompt.
(This assumption is not a new one, just a bit more explicit now.)
On September 11, 2003 "<Someone>" wrote:
> When we're going to have a different save file format, could
> the last messages in the message history be saved as well, so
> ^P would work the same before and after saving (possibly
> including a few less messages to make room for the startup
> messages?).
This seemed like a reasonable request. This patch:
- adds the core support required.
- adds the tty supporting routines.
to allow common parsing in the core, and direct access to the
results by the window port.
Notes:
o Adds a new field, wincap, to the window_procs
structure for setting bits related to the preference
features that the window port supports. This allows
run-time determination of whether a particular option
setting is applicable to the running window port. A
window-port is free to support as many, or as few,
of the available options as it wants. Ensure that
only the ones supported have their corresponding bit
set in window_proc.wincap. [see chart in
doc/window.doc for help with that.]
o The settings I stuck into wincap for each window
port are almost certainly not accurate, so each port
team should review them. You should only include
the ones that you will actually react to and make
adjustments for if the user changes that option.
Without the setting in wincap, the option won't even
show up in the 'O'ptions menu.
o preference_update() added to the window-port
interface, so that the window-port can be notified
if an option of interest (an option with its
corresponding bit set in wincap field) is
changed.
o provided a genl_preference_update() routine in
windows.c and used it for all the existing
window ports since they don't have a functional
one of their own yet.
o this messes around heavily with iflags and the options
arrays in options.c
o I hope I didn't break any port's existing code. I
tried not to. The Mac however, in particular, should
be looked at because it suffered a namespace collision
with what I was working on around fontname. It had
Mac specific font stuff in options.c. Please test
the Mac.
