Re: Console debugging and server applications
Hi Rand,
> A very brief description of the internal solution would be good!
Previously, each picoLisp process - at the moment it switched to raw
mode - obtained the current terminal mode with tcgetattr() and kept it
in a global structure. On program exit, it restored the console to that
value. This means that a child process that was *invoked* when the mode
was "raw" already, would reset the mode to "raw" upon exit, possibly
destroying the "cooked" mode reset by some other process.
Now, only the top level parent process - in main() - queries the mode
with tcgetattr(), keeps it also in a global structure, but inherits it
to each child process. This means that each process that terminates (no
matter in which order) will reset the console to the same state.
The second change (Ctrl-D in the line editor) was even simpler
(lib/led.l:336)
(case "C"
(NIL (bye))
("^D" (prinl) (tell 'bye) (bye))
("^X" (prinl) (quit)) )
Basically, the line with "^D" was added, which tells all other processes
to exit, and then exits itself.
Cheers,
Alex
--
Software Lab. Alexander Burger
Bahnhofstr. 24a, D-86462 Langweid
[EMAIL PROTECTED], www.software-lab.de, +49 8230 5060
Re: Console debugging and server applications
Alex;
Thanks for the explanation and for the fix. I had been struggling
blindly for some time not understanding why I could not get a "clean"
exit. But this should be great now.
Anthony
On Mar 23, 2008, at 10:35 AM, 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 or I have difficulty exiting the application,
requiring several and/or 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
--
Software Lab. Alexander Burger
Bahnhofstr. 24a, D-86462 Langweid
[EMAIL PROTECTED], www.software-lab.de, +49 8230 5060
Re: Console debugging and server applications
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 family.l> or I have difficulty exiting the application,
requiring several and/or 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
