I've not tried to reproduce it, but I think if I code up a forked  
block doing repeated flushAllSuchThat: I think one can recreate the  
problem. Let me look at it tonight.

Possible fix might be below, but I want to review and understand the  
usage of readSynch first since it's inside and outside of the  
accessProtect critical blocks
plus at times we send initSignals to it. Such as nextOrNil:

Yes I need to create a mantis report on this, but wanted to get some  
public visibility to track down people responsible for the code
and to identify if others have seen the problem.


/* Suggested change */

flushAllSuchThat: aBlock
     "Remove from the queue all objects that satisfy aBlock."
     | value newReadPos readSignalsToDo |
     readSignalsToDo := 0.
     accessProtect critical: [
         newReadPos := writePosition.
         writePosition-1 to: readPosition by: -1 do:
             [:i | value := contentsArray at: i.
             contentsArray at: i put: nil.
             (aBlock value: value) ifTrue: [
                 "We take an element out of the queue, and therefore,  
we need to decrement
                 the readSynch signals"
                 readSignalsToDo := readSignalsToDo + 1.
             ] ifFalse: [
                 newReadPos := newReadPos - 1.
                 contentsArray at: newReadPos put: value]].
         readPosition := newReadPos].
     readSignalsToDo timesRepeat: [readSynch wait].
     ^value



On 16-Jun-05, at 6:55 AM, Chris Muller wrote:

> Are you able to reproduce the deadlock easily?
>
>
>

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