When I read you write about fork and threads, I shudder. Fork should
basically not be used when there are active threads. Not just the
Lisp, but the libc, and any library that uses threads or mutexes
(possibly including a threaded malloc) will be mighty confused. I'm
not even sure you can use fork when there is but one thread left after
others die (might or might not work in practice).
In simple cases (static set of mutexes) you can survive with
pthread_atfork (assuming lisp and all libraries play well with it). I
wouldn't bet on it though.
I don't know much about sbcl and its test suite, so I can't comment
about the particulars.
(PS: oh, and the sbcl implementation of run-program has a lot of scary
race conditions. Playing games with aynchronous signal is braindead.)
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it
-- Richard Feynman
2008/5/14 Nikodemus Siivola <nikodemus@...>:
> I'm seeing a fair deal of hanging tests when building threaded on
> Darwin. For ex ample, this
> sh run-tests.sh threads.pure.lisp clos-add-remove-method.impure.lisp
> reliably hangs in the first MAKE-THREAD call in the impure file: the
> thread is spawned, and starts running, but MAKE-THREAD never returns.
> Sticking the same code at the end of threads.pure.lisp shows it
> running fine there, and the test also runs fine if threads.pure.lisp
> has not been run beforehand...
> This particular problem at least seems to be due to problems with
> SB-POSIX:FORK. (Not sure of the exact mechanism yet.) We have three
> different ways of handling thread post-mortem cleanups, but
> SB-POSIX:FORK doesn't deal with any of them -- and at a glance I would
> expect potential problems with at least the Darwin and "default"
> strategies in child processes. Maybe Linux is robust enough that it
> doesn't matter there, or maybe I read the code too hastily, but the
> freeable thread stacks queue seems like a disaster waiting to happen.
> The following patch makes clos-add-remove-method.impure.lisp pass on
> threaded Darwin for me, not that threaded tests are too happy there in
> diff --git a/tests/run-tests.lisp b/tests/run-tests.lisp
> index bcd090d..5d775cd 100644
> --- a/tests/run-tests.lisp
> +++ b/tests/run-tests.lisp
> @@ -79,7 +79,7 @@
> (defun run-in-child-sbcl (load-forms forms)
> (declare (ignorable load-forms))
> - #-win32
> + #-(or win32 (and darwin sb-thread))
> (let ((pid (sb-posix:fork)))
> (cond ((= pid 0)
> (dolist (form forms)
> @@ -90,7 +90,7 @@
> (if (sb-posix:wifexited (aref status 0))
> (sb-posix:wexitstatus (aref status 0))
> - #+win32
> + #+(or win32 (and darwin sb-thread))
> (first *POSIX-ARGV*)
> I'm not sure yet how much time I can spend on this area right now --
> definitely not very much in the Darwin specifics -- so this is mostly
> a heads-up call for everyone interested.
> Apropos, if someone is not seeing this on Darwin... it seems to be a
> bit of a heisenbug: commenting out the last test in threads.pure.lisp
> also makes things pass for me, and it also occasionally passes when
> the CPUs are busy enough, it seems. Gotto love these things.
> -- Nikodemus
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> Sbcl-devel mailing list