Is your code snippet thread safe Andreas?
All "fun and games"!
To be fair, after your delay/semaphore fixes we have what seems a stable
solution for our products. Can never be sure, sometimes, though!
Our system seems to run happily now, around 16 high priority processes and a
few others. Synchronisation in the inportant areas (Squeak can work with an
"optimistic" outlook as long as the critical areas are protected).

Again I'll advocate a "non-preemptive" primitive, on a block, would be nice!

Gary

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org]On Behalf Of
> Andreas Raab
> Sent: 05 December 2007 7:50 PM
> To: The general-purpose Squeak developers list
> Subject: Re: Process>>terminate woes
>
>
> Lukas Renggli wrote:
> > www.squeaksource.com has been successfully running with the recently
> > published Semaphore patches for about a month. This morning we
> > received the attached stack-trace. Going to the image shows that there
> > are thousands of processes waiting at the Semaphore you see in the
> > stack-trace. Cleaning up the mess only helps for a couple of hours,
> > after a while it looks up again ...
> >
> > Any ideas?
>
> Very hard to tell without looking at direct evidence. It may just be a
> problem with your error handler, e.g., that the unwind blocks were not
> run correctly (leaving the semaphore locked). OTOH, it *is* perfectly
> possible that some processes "fell off" the schedulers list. Here is how
> to find out:
>
> Process allInstances reject:[:p|
>      p isActiveProcess
>          or:[p suspendingList == nil
>          or:[p suspendingList includes: p]].
> ].
>
> If this comes up non-empty you are in trouble.
>
> Cheers,
>    - Andreas
>