Mmm let me step back and tackle something that doesn't trash the UI. OK

s _ SharedQueue new.
f _ [[s flushAllSuchThat: [:e | true]. Processor yield] repeat]  
forkAt: Processor userBackgroundPriority.
y _ [[s nextPut: $a.
     e _ s next. Processor yield] repeat ] forkAt: Processor  
userBackgroundPriority


That locks up those two processes, but in the process browser you can  
then inspect and see that
process f sits at readSync wait, and process y sits awaiting the  
critical semaphore that f holds.

Now to propose a fix...



On 16-Jun-05, at 7:36 PM, John M McIntosh wrote:

> Well when I try this, it seems I avoid the deadlock between the two  
> semaphores, but then we trash the
> ReadSync semaphore, or something certain happens.
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===