Hi Alex,
first: good news, and congratulations. A very brief description of the
internal
solution would be good!
Thanks, Rand
Randall Dow
Witneystrasse 7, D-82008 Unterhaching, Germany
phone: +49-89-12417690 mobile: +49-176-24129991
Alexander Burger wrote:
Today, Anthony Sherbondy brought up a question that also troubled me
since a long time:
For example, when I have an application running (either <doc/
family.l> or <app/main.l> I have difficulty exiting the application,
requiring several <Control-X> and/or <Control-C> attempts to escape.
When I do finally exit and I am in terminal (bash shell) I can type
commands ("exit" for example), but I cannot see them on the screen.
The good news first: I think I found a good solution!
But let me first try to explain the situation. If you start up a server
application with something like
./p dbg.l xxx/main.l -main -go
it will sit there and wait for a browser to connect. If you hit Ctrl-C
now, it will terminate, and everything will be OK.
As soon as a browser connects, the server process will spawn a child
process, and display the ':' prompt for interactive debugging. Because
"dbg.l" was loaded, this debugging session will switch the console to
"raw" mode, meaning that all character processing is now handled by
picoLisp itself.
This means, for example, that Ctrl-C is caught, so that it will no
longer kill the whole process, but interrupt a running program in a
controlled way to enter a picoLisp breakpoint.
To terminate such a session, the recommended way is to type a single
ENTER. This will cause the child process to exit. Before it does so, it
will reset the console to the normal "cooked" mode. The server continues
to run, and will accept further browser requests, but can be killed with
Ctrl-C any time, because the console is in "cooked" mode again.
Problems arise when you connect the browser a second time, *before* the
first child process exited. Then suddenly two processes are listening on
the console for key strokes, competing for user input, and it is not
predictable which process will receive which key. Usually the input to
both processes will be garbled.
The second problem resulting from the situation of multiple processes on
a single console was that hitting ENTER repeatedly would terminate all
child processes, but leave the console in "raw" mode sometimes, because
the order in which the child processes was not defined and could result
in undesired effects.
That's why I always took care to first terminate a debugging session
with ENTER before re-connecting the browser, or hitting Ctrl-C to stop
it all. Unfortunately, during heavy testing, I also forgot to do so from
time to time and ended up with a raw console. (The usual Unix remedy to
that is to type blindly "stty sane" followed by a Ctrl-J)
Now, however, the situation should be greatly improved. In the new
testing version (to be released as 2.3.2 at the end of this month), I
just introduced two modifications:
1. The cooked/raw mode handling is changed now, so that the order of
process termination should not influence the final result (a cooked
console) after all processes exited.
2. The command line editor now understands Ctrl-D as a command to
terminate *all* child processes (including itself).
This means:
- Hitting ENTER once will terminate the *current* process (as
before).
- Hitting ENTER repeatedly will terminate all child processes (as
before), however it will *not* leave the console in raw mode any
longer.
- Hitting Ctrl-D will also terminate the current process, but
possibly also all other siblings. This is equivalent to as many
ENTER hits as there are child processes.
So, the simple rule is: If you are lost on the console, and not sure
what's going on, you can clean up the whole mess by typing just two key
strokes
Ctrl-D Ctrl-C
no matter if there are zero, one or many child processes running.
That's it.
Cheers,
Alex
