specialObjectsArray issues

Tim Rowledge tim at sumeru.stanford.edu
Thu Jul 24 19:40:46 UTC 2003


"Andreas Raab" <andreas.raab at gmx.de> wrote:

> > TranslatedMethod class initialize & PseudoContext class 
> > initialize - (do we even actually want TranslatedMethod
> > and PseudoContext in the current releases?) checks the
> > array size = 41, which stopped being true a long time ago.
> 
> Well, fix it ;-)
Sure - but fix it by removing TranslatedMethod or by increasing 41 to
49? The latter is nicely trivial but the former seems cleaner. A cursory
scan of all the souces I can get my hands on suggests there isn't any
use of either of them now. Is J3 in use anywhere? Is it likely to be? If
we take them out how hard will it be to put them back if a working Jit
turns up - not too hard, I'd say, but it isn't my sole opinion that
matters.


> 
> > EventSensor initialize - checks to see if special objects includes a
> > semaphore for the inputSemaphore.
> 
> The _interrupt_ semaphore not the input semaphore.
Dang, you're right. I let myself get confused by the comment in -
recreateSpecialObjectsArray    "Smalltalk recreateSpecialObjectsArray"
	"The Special Objects Array is an array of object pointers used by the
	Squeak virtual machine.  Its contents are critical and unchecked,
	so don't even think of playing here unless you know what you are doing."
	| newArray |
	newArray _ Array new: 50.
	"Nil false and true get used throughout the interpreter"
	newArray at: 1 put: nil.
	newArray at: 2 put: false.
	newArray at: 3 put: true.
[snip]
	newArray at: 30 put: (self specialObjectsArray at: 30)   "(delay
Semaphore)".
	newArray at: 31 put: (self specialObjectsArray at: 31) "(user input
Semaphore)".
[snip]
which is pretty clear and obviously wrong :-(  Now that I _can_ fix
easily enough.

> 
> > Oddly enough, since the external semaphores system went in
> > there is no likely way that there would be a semaphore in
> > the array.
> 
> Oh, but absolutely - just check Interpreter>>checkForInterrupts. We still
> have both the timer and the interrupt semaphore in the spl objects.
Hmm, indeed we do. Note that the inputSemaphore is dealt with via the
ExternalSemaphore array but the interruptSemaphore and lowSpaceSemaphore
aren't. I suppose one can make the argument that the lowSpaceSem
wouldn't need to be since it is only triggered internally to the core
vm. The interruptSemaphore seems to be considered obsolete according to
comments in EventSensor, although I see that Mac and Acorn are
still actually triggering it directly in their keypress handlers. In the
Acorn case it will continue to since cmd-. is not at all in the RiscOS
idiom.

Ho hum, I guess I'll submit a couple of changesets and see what people
think.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Design: The activity of preparing for a design review.



More information about the Squeak-dev mailing list