quasi <quasiabhi@gmail.com> wrote:
+---------------
| The application creates multiple process with mp:make-process and each
| of the processes then opens a connection with a java server (using
| trivial-socket:open-stream) to get some data.  This call is wrapped in
| with-open-stream so it should close stream when done with.  It's a
| simple operation and works well.  But if there are open connections
| with the java server and the server dies (or is killed because it hung)
| then the lisp goes into continuous GC taking 99% CPU. This also occurs
| when we take the network interface down (experiment). I have used the
| code from araneida, the forcibly-close-socket and it still does not help.
+---------------

Hmmm... You may be running into something that bit me with my
CMUCL-based server several years ago, namely, if the thing on
the other end of a socket goes away, then you'll get a SIGPIPE
the next time to write to it, which by default will call ERROR
and print a message before entering the debugger. But if the
*ERROR_OUTPUT* stream happens to be bound to the very Unix file
descriptor that you just got the SIGPIPE on... Oops!! Infinite
recursion. (Which can cause an infinite string of GCs due to
consing in the signal handler, although the actual CPU saturation
isn't *caused* by the GC per se.) If this is your problem, a
solution is described in some detail in an article I posted here
last December [you may need to click on "Show original" to get
decent formatting]:

    http://groups.google.com/group/comp.lang.lisp/msg/ee284119a99c0d68

But briefly, the trick [due to Dan Barlow] is to *ignore* SIGPIPE,
and let the normal I/O error handing take over. [Writes will result
in EPIPEs, not signals.]

Hope that helps...


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607