On Sun, 26 Oct 2014, Bert Freudenberg wrote:

>
> On 26.10.2014, at 10:32, David T. Lewis <lewis at mail.msen.com> wrote:
>
>> On Sun, Oct 26, 2014 at 02:06:20AM +0200, Levente Uzonyi wrote:
>>> I've uploaded the new versions of the packages to The Inbox, and moved the
>>> old ones to The Treated Inbox.
>>> The main difference is that the Semaphore class is not modified, and its
>>> instances are handled like any other object. There's also a new #cleanUp:
>>> method which will allow freeing up some memory. And the caches are
>>> shrinked whenever the external objects are wiped.
>>> Since Semaphores don't know their indexes anymore, the new part of the API
>>> has also changed.
>>> The following snippet will load the new versions to an up-to-date Trunk
>>> image:
>>>
>>> Installer squeakInbox
>>> 	package: 'System-ul.687';
>>> 	package: 'Sound-ul.40';
>>> 	package: 'Kernel-ul.883';
>>> 	package: 'Network-ul.154';
>>> 	package: 'Files-ul.140';
>>> 	install
>>>
>>
>> This looks really good to me. I vote for moving it to trunk.
>>
>> Dave
>
> Yes, the implementation itself looks good.
>
> It's just a bit unfortunate that the user code gets even less generic than it was before.

What do you mean by "less generic"? Is it that the code says 
ExternalSemaphoreTable instead of Smalltalk?
The code was extracted from Smalltalk more than 14 years ago, because

"It seemed cleaner to deligate the reponsibility here versus adding more code and another class variable to SystemDictionary"

I could have left all (indirect) users of the ExternalSemaphoreTable 
unchanged, but I think we really should make SmalltalkImage less 
monolithic and remove those "proxy" methods from it in the near future. 
The new methods give additional performance boost (because we know that 
the Semaphores are new, so we don't have to check if they are already 
included, and because we don't have to wait for the lock multiple times, 
when multiple Semaphores are registered or unregistered) especially for 
Sockets, which was the main reason I spent so much time on this.

Levente

>
> - Bert -
>
>