On Thursday 24 March 2005 08:33, Cees de Groot wrote:
> On Thu, 24 Mar 2005 01:20:42 +0100, Cees de Groot <cg at cdegroot.com> wrote:
> > (I've rewritten the retranmission code to use a single process, let's
> > see whether that makes a difference)
>
> Nope. Hung again. Oh well, at least I got to use the Heap class :P
>
> The symptoms with the current image are the same - not 900 processes, but
> lots of processes in identical state:
>
> Semaphore>>critical:
> Delay>>schedule
> Delay>>wait

After lots of http requests (web spider), I get the same stactrace (via gdb), 
and yes, a single  process is enough to hang. I tried various http 
implementations, as well as the replacing SocketStream with FastSocketstream. 

I somehow suspect the socket and timeout code, but have not yet found a way to 
pinpoint it , nor create a test that fails fast enough (my integration test 
fails after one to several hours, that makes the try and fix cycle a bit 
long...).  

To make sure it was not somewhere in my squeak code, I tried a fourth variant 
for downloading pages: create a http request object that uses ruby to do http 
rather than squeak. That works like a charm, no more hangs, almost no more 
timeout errors... 

Only thing is, that it doesn't package so elegantly. I'd prefer squeak to work 
out of the box rather than using a workaround which I consider to be fairly 
ugly.

The sites my spider failed on are sites that are rather slow in providing 
data, that may have something to do with it.

what your problem and mine seem to have in common is lots and lots of  calls 
to Semaphore critical: and Delay wait:

I saw you also tried scheduler priority tweaks. That doesn't seem to matter. 
Oh, and hangs also under windows as well as under linux.

Just another datapoint. I have no idea for a solution yet. 

cheers,

-- 
Willem van den Ende
weblog: http://ruminations.willemvandenende.com