On Sat, Oct 25, 2014 at 01:07:31AM +0200, Levente Uzonyi wrote:
> On Fri, 24 Oct 2014, David T. Lewis wrote:
> 
> >On Fri, Oct 24, 2014 at 09:52:11PM +0200, Levente Uzonyi wrote:
> >>On Fri, 24 Oct 2014, Bert Freudenberg wrote:
> >>
> >>>Another thought: is it really necessary to cache the index in the
> >>>semaphore? Wouldn't scanning the externalObjectsTable for self be
> >>>efficient enough? It's pretty small, after all.
> >>
> >>That's exactly what the current implementation does (scans the table), and
> >>this is what I want to avoid, because it doesn't scale. The table is small
> >>when you start your image, but it can easily grow large - especially on a
> >>server (3 semaphores per socket) - and it never gets shrinked. So once it
> >>grows, it'll stay slow "forever".
> >>
> >>And no, it's not absolutely necessary to store the index in the
> >>semaphores. The new implementation uses an IdentityDictionary to store the
> >>indexes of non-semaphores. The same method could work for semaphores too.
> >>But it's convenient to store the index in the semaphore, otherwise the
> >>method which creates and registers a new semaphore has to return two
> >>values - the index and the semaphore - which is cumbersome.
> >>It's also faster to ask for a new Semaphore from the
> >>ExternalSemaphoreTable, because that way it knows that the
> >>Semaphore is not registered.
> >
> >I also like the implementation overall, but it seems to me that a Semaphore
> >should not be responsible for knowing about whether somebody used it in the
> >external objects array. It seems more natural for ExternalSemaphoreTable
> >to be responsible for keeping track of the relationship between semaphores
> >and external resources. Thus I don't really like the 
> >#indexInExternalObjectsArray
> >instance variable in Semaphore.
> >
> >On the other hand, in your earlier post introducing this topic, you said:
> >
> >> I also thought that I'll create a special semaphore (ExternalSemaphore -
> >> which is a subclass of Semaphore) that knows its own index in the 
> >> external
> >> objects array.
> >
> >So IMO, maybe maybe your original concept is better, even if it requires
> >another class. An ExternalSemaphore would be a Semaphore that knows about
> >its place in the ExternalObjectsArray, but semaphores in general do not
> >need to know about that.
> >
> >I'm not sure which would be better, but it seems to me that either
> >ExternalSemaphoreTable should be responsible for maintaining the 
> >relationship
> >(presumably with an IdentityDictionary), or ExternalSemaphore should be
> >a kind of semaphore that knows something more about its place in the world.
> 
> The problem with ExternalSemaphore idea is that it requires VM changes. 
> The VM is not willing to signal instances of non-Semaphores. AFAIK 
> signaling is based on what's in slot 19 of the specialObjectsArray. But 
> changing the class there is not possible, because other VM mechanisms also 
> rely on the content of that slot.

Hmm... Unfortunately you are right.

	InterpreterPrimitives>>primitiveSignal
	"synchromously signal the semaphore. This may change the active process as a result"
		| sema |
		sema := self stackTop.  "rcvr"
		self assertClassOf: sema is: (objectMemory splObj: ClassSemaphore).
		self successful ifTrue: [ self synchronousSignal: sema ].

Dave