Hello Lutz,
The function 'process backgrounds a process, which under unix/linux can
cause <defuncs> (not so bad as long as newlisp tracks the child ).
These <defuncs> are caused by IO under unix/linux, but...
To be able to controll this 'process launched by newlisp it would be very handy
to have a PID returned. This way under newlisp the child can still be killed
from within newlisp, rather beining on itself and kills when newlisp is closed.
example:
> ( process "lisple" )
12302
>(define (killpid pid) (import "/lib/libc.so.6" "kill") (kill pid 9))
0
Norman.
process
this is what I can do in 7.5.8 (you can do it now to try out):
in nl-filesys.c in the function p_process() (there are two versions for Win32 and UNIX):
change the last line:
old: return(true);
new: return(stuffInteger(forkResult));
This will give you the pid of the newLISP child process, that pid+1 is the pid of the process launched by the child process.
i.e:
(process "kedit") => 2412
2412 => newLISP childprocess
2413 => kedit pid
Lutz
in nl-filesys.c in the function p_process() (there are two versions for Win32 and UNIX):
change the last line:
old: return(true);
new: return(stuffInteger(forkResult));
This will give you the pid of the newLISP child process, that pid+1 is the pid of the process launched by the child process.
i.e:
(process "kedit") => 2412
2412 => newLISP childprocess
2413 => kedit pid
Lutz
Hello Lutz,
Yes the implant works, but its impossible to kill his PID afterwards, thats due to the fact that the process belongs to newlisp. If newlisp would stop
and the child will stay there as defunc then still you cant kill the child,
so actualy the process PID return is of no use :-) I thought it would, but
its useless.. :-)
Norman.
Yes the implant works, but its impossible to kill his PID afterwards, thats due to the fact that the process belongs to newlisp. If newlisp would stop
and the child will stay there as defunc then still you cant kill the child,
so actualy the process PID return is of no use :-) I thought it would, but
its useless.. :-)
Norman.
If this issue is about reaping DEFUNCT child processes, I had the same problem with my GTK-server. This sample C code can be used to solve it. It will callback a C function which cleans up the defuncts, so you do not have to exit newLISP. Maybe you can test it yourself, newdep... :-)
-------------------------
/* Declare struct */
struct sigaction sa;
/* Register zombie process reaper with callback function */
sa.sa_handler = sig_handler;
/* Do not block other signals */
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_RESTART;
if (sigaction(SIGCHLD, &sa, NULL) < 0) {
printf("Could not set signal handler!\n");
perror("sigaction");
exit(-1);
}
-------------
/* Callback for reaping defuncts */
void sig_handler(int signal)
{
int status;
/* Reap child without blocking */
if (waitpid(-1, &status, WNOHANG) < 0) return;
}
-------------------------
/* Declare struct */
struct sigaction sa;
/* Register zombie process reaper with callback function */
sa.sa_handler = sig_handler;
/* Do not block other signals */
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_RESTART;
if (sigaction(SIGCHLD, &sa, NULL) < 0) {
printf("Could not set signal handler!\n");
perror("sigaction");
exit(-1);
}
-------------
/* Callback for reaping defuncts */
void sig_handler(int signal)
{
int status;
/* Reap child without blocking */
if (waitpid(-1, &status, WNOHANG) < 0) return;
}