From: Faré <fa...@gm...> - 2010-04-29 23:16:00
|
POIU used to work on CLISP, but something on current debian clisp breaks it - probably some SIGCHLD handler or library function eating the results from waitpid - do you know if such a thing is happening, and if so is there an API to catch the pids? It might be something installed as part of common-lisp-controller. Or not. So I tried to compile clisp from cvs with clbuild, but it doesn't include the LINUX package, and I can't fathom how to ./configure it. The documentation seems to suggest --with-module=glibc but --with-module is not recognized. Am I doing something wrong? What's the correct way to configure clisp to have all the modules possible compiled in? Thanks for your help, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Economic illiteracy often leads one to take for wealth creation or cost reduction what is only a forced displacement of activity, with no primary gain, and a lot of secondary costs and negative side-effects. — Faré |
From: Sam S. <sd...@gn...> - 2010-04-30 14:22:39
|
Faré wrote: > POIU used to work on CLISP, but something on current debian clisp > breaks it - probably some SIGCHLD handler or library function eating > the results from waitpid - do you know if such a thing is happening, > and if so is there an API to catch the pids? I am sorry, I do not understand what you are talking about. Maybe you could supply a test case? > The documentation seems to suggest --with-module=glibc but > --with-module is not recognized. Am I doing something wrong? clisp comes with the file INSTALL in the top-level directory. you mention debian, so clisp/INSTALL would refer you to clisp/unix/INSTALL which contains detailed, step-by-step instructions. E.g., 12. If you are lazy and have too few spare neurons to remember this long process, just use the shortcut, like I do: ./configure --with-module=rawsock --cbc build-dir this covers the build process through step 8 (except mod-check). > What's > the correct way to configure clisp to have all the modules possible > compiled in? you cannot "compile in" all modules because some are platform-specific (e.g., bindings/win32 and bindings/glibc) and some conflict with each other (e.g., clx/mit-clx and clx/new-clx) use "./configure --help-modules" to get the list of available modules. Sam. |
From: Faré <fa...@gm...> - 2010-04-30 16:51:42
|
On 30 April 2010 09:30, Sam Steingold <sd...@gn...> wrote: > Faré wrote: >> >> POIU used to work on CLISP, but something on current debian clisp >> breaks it - probably some SIGCHLD handler or library function eating >> the results from waitpid - do you know if such a thing is happening, >> and if so is there an API to catch the pids? > > I am sorry, I do not understand what you are talking about. > Maybe you could supply a test case? > I think the issue is that CLISP somehow ignores SIGCLD or handles it. I need to keep the handler be the default, so I can waitpid. I don't understand the sigaction interface of CLISP -- how do I determine what is the handling status of a signal (default, ignored, handler), and how to I reset it to default? >> The documentation seems to suggest --with-module=glibc but >> --with-module is not recognized. Am I doing something wrong? > > clisp comes with the file INSTALL in the top-level directory. > you mention debian, so clisp/INSTALL would refer you to clisp/unix/INSTALL > which contains detailed, step-by-step instructions. > OK. I was trying to configure from src/ which is the wrong directory - first configure on top, then cd src and make. >> What's >> the correct way to configure clisp to have all the modules possible >> compiled in? > > you cannot "compile in" all modules because some are platform-specific > (e.g., bindings/win32 and bindings/glibc) and some conflict with each other > (e.g., clx/mit-clx and clx/new-clx) > Could there be an autodetection kit that includes all modules that are available, and defaults clx to new-clx (or whichever is latest or most maintained). --#f "I carry a gun because a cop is too heavy." — R. Lee Wrights |
From: Sam S. <sd...@gn...> - 2010-04-30 17:14:38
|
Faré wrote: > On 30 April 2010 09:30, Sam Steingold <sd...@gn...> wrote: >> Faré wrote: >>> POIU used to work on CLISP, but something on current debian clisp >>> breaks it - probably some SIGCHLD handler or library function eating >>> the results from waitpid - do you know if such a thing is happening, >>> and if so is there an API to catch the pids? >> I am sorry, I do not understand what you are talking about. >> Maybe you could supply a test case? >> > I think the issue is that CLISP somehow ignores SIGCLD or handles it. of course, clisp starts processes (run-program et al) and has to handle sigcld. > I need to keep the handler be the default, so I can waitpid. are you using linux:waitpid? why? posix:wait handles the issue by disabling handling of sigcld around waitpid(2). http://clisp.cons.org/impnotes/syscalls.html#wait > I don't understand the sigaction interface of CLISP -- how do I > determine what is the handling status of a signal (default, ignored, > handler), and how to I reset it to default? clisp "owns" signals. it uses many signals internally (more in MT) and it is not a good idea to interfere with it. >>> The documentation seems to suggest --with-module=glibc but >>> --with-module is not recognized. Am I doing something wrong? >> clisp comes with the file INSTALL in the top-level directory. >> you mention debian, so clisp/INSTALL would refer you to clisp/unix/INSTALL >> which contains detailed, step-by-step instructions. >> > OK. I was trying to configure from src/ which is the wrong directory - > first configure on top, then cd src and make. actually, the best way is to build in a separate directory, not src. this way you can have several coexisting builds. >>> What's >>> the correct way to configure clisp to have all the modules possible >>> compiled in? >> you cannot "compile in" all modules because some are platform-specific >> (e.g., bindings/win32 and bindings/glibc) and some conflict with each other >> (e.g., clx/mit-clx and clx/new-clx) >> > Could there be an autodetection kit that includes all modules that are > available nope. if you have a certain library installed in a non-standard place, you can still use it: ./configure --with-module=postgresql --with-libpq-prefix=${HOME}/local surely you do not want me to add "find / -name libpq*" to the top-level configure? however, I, personally, use this bash function: mkcli(){ # make CLISP unset mycc if [ -z "$1" ]; then echo "usage: ${FUNCNAME} build-dir" 2>&1; return 1; fi MODS="rawsock wildcard"; CFG="./configure --cbc CFLAGS=''"; test -f ${SRC_DIR}/top/include/avcall.h && \ CFG=${CFG}" --with-libffcall-prefix="${SRC_DIR}/top case "$1" in (build*) dir=$1; ;; (*) dir=build-$1; ;; esac case ${dir} in (*-g-* | *-g) CFG=${CFG}' --with-debug'; DEBUG=true ;; esac case ${dir} in (*-gxx*) mycc=g++ ;; esac case ${dir} in (*-m64*) mycc=${mycc-gcc}' -m64'; SUFFIX=/m64; ;; esac case ${dir} in (*-m32*) mycc=${mycc-gcc}' -m32'; SUFFIX=/m32; ;; esac case ${dir} in (*-nodm*) CFG=${CFG}' --without-dynamic-modules'; ;; esac case ${dir} in (*-noU*) CFG=${CFG}' --without-unicode'; ;; esac case ${dir} in (*-mt*) CFG=${CFG}' --with-threads=POSIX_THREADS'; ;; esac case `uname` in (Linux) MODS=${MODS}' bindings/glibc' ;; (CYGWIN*) MODS=${MODS}' dirkey bindings/win32'; SIGSEGV=cygwin; test -z "$DEBUG" && NOX=true ;; (SunOS) for e in readline sigsegv iconv; do CFG=${CFG}" --with-lib${e}-prefix=${HOME}/src/sun4${SUFFIX}"; done ;; esac case ${dir} in (*-mingw*) CFG=${CFG}' --with-mingw'; SIGSEGV=mingw; # MINGW=/MinGW; # for d in pcre zlib sigsegv; # do CFG=${CFG}" --with-lib$d-prefix=${MINGW}"; done # MODS=${MODS}' pcre zlib dirkey bindings/win32'; ;; (*) test -f /usr/include/db.h && MODS=${MODS}' berkeley-db'; test -f /usr/include/zlib.h && MODS=${MODS}' zlib'; test -d /usr/include/pcre -o -f /usr/include/pcre.h && MODS=${MODS}' pcre'; test -d /usr/include/gdbm -o -f /usr/include/gdbm.h && MODS=${MODS}' gdbm'; test -d /usr/include/X11 -a -z "$NOX" && MODS=${MODS}' clx/new-clx'; test -d /usr/include/pari && MODS=${MODS}' pari'; test -d /usr/include/gtk-2* -a -d /usr/include/libglade-2* && MODS=${MODS}' gtk2'; test -d /usr/include/dbus-1* && MODS=${MODS}' dbus'; test -f /usr/include/svm.h -o -d /usr/include/libsvm* && MODS=${MODS}' libsvm'; ;; esac if test -f c:/progra~1/postgresql/*/include/postgres_ext.h; then MODS=${MODS}' postgresql'; CFG=${CFG}" --with-libpq-prefix=c:/progra~1/postgresql/*"; elif test -f /usr/local/include/postgres_ext.h \ -o -d /usr/local/include/postgresql; then MODS=${MODS}' postgresql'; CFG=${CFG}" --with-libpq-prefix=/usr/local"; elif test -f /usr/include/postgres_ext.h -o -d /usr/include/postgresql; then MODS=${MODS}' postgresql'; fi test -z "${SIGSEGV}" || \ CFG=${CFG}' --with-libsigsegv-prefix=/usr/local/libsigsegv-'${SIGSEGV}; /bin/rm -rf ${dir}; if test -L build; then rm -fv build; fi ln -sv ${dir} build; export CONFIG_SHELL=/bin/sh for m in ${MODS}; do CFG=${CFG}" --with-module=$m"; done test -z "${mycc}" || CFG=${CFG}" CC='${mycc}'" echo "${CFG} ${dir}"; ${CFG} ${dir} | tee ${dir}.log; } |
From: Faré <fa...@gm...> - 2010-05-01 21:05:08
|
On 30 April 2010 13:14, Sam Steingold <sd...@gn...> wrote: >> I think the issue is that CLISP somehow ignores SIGCLD or handles it. > > of course, clisp starts processes (run-program et al) and has to handle > sigcld. > Sure. But then, the API needs to make it possibly to play nice. For instance, SBCL's run-program installs its signal handler when run-program is called, which allows single-threaded programs to handle their own children while run-program is not being used, whereas run-program too will run fine when there aren't other children. It's primitive, but it works. Another way to do things would be for wait to callback hooks whenever it receives a death notice from the kernel, so the interested parties can be notified that their children are dead. Dropping notifications, either by ignoring the signal or by handling it then ignoring children that are not related to run-program, is always the wrong thing to do. >> I need to keep the handler be the default, so I can waitpid. > are you using linux:waitpid? why? > posix:wait handles the issue by disabling handling of sigcld around > waitpid(2). > http://clisp.cons.org/impnotes/syscalls.html#wait > I'm using posix:wait, as per your previous recommendations. However, handling of SIGCHLD should be in SIG_DFL state *all the time*, not just around calls to wait itself, for signals not to be dropped. I'd implement a special case "if wait tells you there are no children, then you lost a signal and can mark the whole wait queue as dead", except that somehow, due to my frobbing CLISP, ASDF and/or POIU, I now get an error in the preparation phase with CLISP that I'm not getting with either SBCL or CCL. Sigh. > clisp "owns" signals. it uses many signals internally (more in MT) and it is > not a good idea to interfere with it. > It's OK for clisp to own them - but then it should provide an API for users to be notified of dead children in a timely fashion. > actually, the best way is to build in a separate directory, not src. > this way you can have several coexisting builds. I'll have to (re)read INSTALL carefully to understand what that means. Thanks for your support, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If once you have paid him the Dane-geld / You never get rid of the Dane. — Rudyard Kipling |
From: Sam S. <sd...@gn...> - 2010-05-03 21:10:54
|
Faré wrote: > However, handling of SIGCHLD should be in SIG_DFL state *all the time*, > not just around calls to wait itself, for signals not to be dropped. spvw_sigcld.d says: /* Our general policy with child processes - in particular child processes to which we are connected through pipes - is not to wait for them, but instead do what init(1) would do in case our process terminates before the child: perform a non-blocking waitpid() and ignore the child's termination status. void handle_child () { while (waitpid(-1,NULL,WNOHANG) > 0); } SIGNAL(SIGCLD,handle_child); The following is equivalent (but better, since it doesn't interrupt system calls): SIGNAL(SIGCLD,SIG_IGN); */ yes, we can enable ignoring sigcld only while running a shell command. alas, this will not help the multithreaded case because signal handling is per-process, not per-thread, and if two threads start children, they fail. for now, you can just do (ffi:def-call-out begin_want_sigcld (:arguments) (:return-type nil)) (ffi:def-call-out end_want_sigcld (:arguments) (:return-type nil)) Vladimir, what do you think should the long term solution be? |
From: Vladimir T. <vtz...@gm...> - 2010-05-04 09:08:37
|
On Tue, May 4, 2010 at 12:10 AM, Sam Steingold <sd...@gn...> wrote: > Faré wrote: >> >> However, handling of SIGCHLD should be in SIG_DFL state *all the time*, >> not just around calls to wait itself, for signals not to be dropped. I agree - we should not ignore SIGCHLD by default but rather install signal handler and waitpid non-blokcingly. > yes, we can enable ignoring sigcld only while running a shell command. > alas, this will not help the multithreaded case because signal handling is > per-process, not per-thread, and if two threads start children, they fail. Currently nothing is done for SIGCHLD in mt builds and there are races if two threads use begin/end_want_sigcld(). Installing signal handler and axing begin/end_want_sigcld() looks like will fix this. In mt we can add status-function to be called on process status change (like in sbcl) but some problems will arise: 1. win32 does not have similar mechanism for process status change updates? 2. in what thread context the status-function will be called (not a big issue but adds uncertainty - the thread that forked the process may have exited)? 3. the same is not applicable in single thread build - there is no thread-interrupt and from the signal handler nothing can be done (in mt SIGCLD will be handled with sigwait in this case - like all other signals). So unless there is good reason to ignore SIGCHLD by default (?) I think that regular signal handler will do for both single and mt builds. |