On 17 Oct 2006, Eric Marsden spake thusly: >>>>>> "qu" == quasi <[EMAIL PROTECTED]> writes: > > qu> Firstly, I am using trivial-sockets to make HTTP connections. We > qu> have seen that whenever we try to connect to a system which is > qu> down, or when my interface has gone down, CMUCL goes into > qu> continuous GC taking up 99% CPU. This is when MP is > qu> initialised. > > this sounds like a bug in the interaction between CMUCL's network > code and the SERVE-EVENT facility. Probably the file descriptor > corresponding to the failed network connection has not been marked > as being inactive, and select() is being called continually. > > Are you able to provide a simple test case, preferably using CMUCL > builtin functions rather than trivial-socket calls?
I am trying to build one. But it is a bit complicated for me. I have observed another case where the network connection is ok but the function which does the parsing of the data from that connection throws an error - parse-integer in specific - the same thing happens. But it does not seem to happen when I tried to replicate it for a single process. I also tried spawning about 50 processes which sleep for a random time and then throw an error (parse-integer nil) to see if it had something to do with too many processes throwing errors. All I found out was slime cannot handle it. :) I will try with the CMUCL built in functions for the socket example as you suggest. thanks for responding. -- quasi Utopia Unlimited!
