[squeak-dev] Questions about external objects
David T. Lewis
lewis at mail.msen.com
Sat Oct 25 00:00:12 UTC 2014
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
> >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
> >(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.
"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 ].
More information about the Squeak-dev