Alexander Burger <a...@software-lab.de> writes: Hi Alex,
>> is it "normal" that a simple 'kill' won't kill PicoLisp processes, only >> with option 'KILL it works? > > No. > > A "normal" kill with SIGTERM (i.e. -15) should work. > > SIGKILL (i.e. -9) should be used only in extreme emergencies, because it > may cause the loss of data (resulting in a corrupted database in the > worst case)! > > > Usually a > > $ killall picolisp > > or > > $ killall pil > > should do. > > > It should be noted, however, that PicoLisp catches some signals: > > 1. SIGPIPE, SIGTTIN and SIGTTOU are ignored. > > 2. SIGIO is caught and handled in the 'sigio' function handler. > > 3. SIGHUP is caught and handled in the '*Hup' global. > > 4. SIGUSR1 and SIGUSR2 are handled in the '*Sig1' and '*Sig2' > globals. > > 5. SIGALRM is used for the 'alarm' and 'abort' functions. > > 6. SIGCHLD is handled internally for the management of child > processes. > > 7. SIGINT is caught only in the REPL, and causes a console break. A > process running without a REPL is terminated. > > 8. SIGTSTP is used in the REPL to suspend the forground PicoLisp > process. > > > The "normal" (default) signal SIGTERM causes the termination of the > running PicoLisp process with 'bye'. > > BUT: > 1. If that process has still running child processes, it sends > SIGTERM recursively to all children first, and waits for them to > terminate. Then it terminates itself. > > 2. During certain phases of program execution, the PicoLisp > interpreter blocks this and/or other signals. This may be in a > 'protect'ed code block, or during critical database operations. > This will only delay the handing of those interrupts (not ignore > them). > > I hope I didn't forget anything :) Guess not, that reads like an exhaustive treatment ;) Thanks for the info. I ran into this problem when experimenting with the web-framework and my app got into a bad state. When restarting then, PicoLisp tells me something like 'Port is already used', so I tried to kill the still running (*) PicoLisp processes with a simple 'kill PID', but to no avail. [* are they still running? 'ps' shows them with a '?', and I shutted them down on the command-line, so they shouldn't. But somehow they still block the port, and the more I shut down, the more are shown by 'ps'] May that be because things went wrong during debugging when some database operation failed? I have no idea ... -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
