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.

>
> - Bert -
>
> On 24.10.2014, at 11:44, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
>> Your implementation looks good.
>>
>> But if we're changing the API, can we get around exposing ExternalSemaphoreTable to user code? It is an implementation detail, after all.
>>
>> E.g. for file opening:
>>
>> 	semaphore := Semaphore new.
>> 	fileHandle := self primOpen: name asVmPathName forWrite: writeable semaIndex: semaphore registerExternalIndex.
>> 	fileHandle ifNil: [
>> 		semaphore unregisterExternalIndex.
>> 		semaphore := nil.
>> 		^ nil].
>>
>> I'm not sure about the exact selectors, but this would make the programmer not having to deal with the implementation detail of the table at all.

Yes, it's possible to extend the API by adding a few methods to 
Semaphore.


Levente

>>
>> - Bert -
>>
>> On 24.10.2014, at 08:22, Levente Uzonyi <leves at elte.hu> wrote:
>>
>>> Thanks Bert. It turned out that my image was already broken when I tried to add an instance variable to Semaphore.
>>> I've finished the implementation and uploaded it to The Inbox. The following snippet will load it into an updated Trunk image:
>>>
>>> Installer mc
>>> 	http: 'source.squeak.org';
>>> 	project: 'inbox';
>>> 	package: 'Kernel-ul.881';
>>> 	package: 'System-ul.686';
>>> 	package: 'Kernel-ul.882';
>>> 	package: 'Sound-ul.39';
>>> 	package: 'Network-ul.153';
>>> 	package: 'Files-ul.139';
>>> 	install
>>>
>>> I decided to go with the complex solution, which gives the best performance, and a simple API for Semaphores, but also has pretty good performance for any other object. And it's backwards compatible in almost all cases.
>>>
>>> Levente
>>>
>>> On Sun, 12 Oct 2014, Bert Freudenberg wrote:
>>>
>>>> On 12.10.2014, at 08:04, Levente Uzonyi <leves at elte.hu> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I found that the handling of external objects is suboptimal in the image, and I came up with some ideas to make it better. I have a working solution in my image, but it can be even better.
>>>>>
>>>>> It seems to me that only Semaphores are stored in the external objects array (slot 39 in the special objects array), but in practice any object can be stored there. Does it make sense to support objects of any other kind? If not, then the code could be simplified.
>>>>
>>>> Currently the VM uses the ExternalObjectsArray only for semaphores. Other objects use different mechanisms (e.g. SurfacePlugin for external forms). I'm not sure if there is a good use case for storing non-semaphores in ExternalObjectsArray, maybe ask on the vm-dev list?
>>>>
>>>>> 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. This could be really handy for finding the object in the array, but the VM is not willing to signal these semaphores in the external objects array. I thought that this is because the VM doesn't know anything about this class.
>>>>> So I tried to change Semaphore itself, but after the change the VM refused to signal any semaphores in the external objects array. Changing the class back to the original didn't help either. Without looking at the VM code, I assumed that the VM will signal anything which has the class in the 19th slot of the special objects array, but that doesn't seem to be the case.
>>>>> Is there any way to make this (add an instatnce variable to Semaphore and still get signals from the VM, or use instances of a subclass of Semaphore there) work?
>>>>
>>>> The VM only checks for the exact class in slot 19, not for subclasses. Adding an inst var to Semaphore itself should be fine, but you cannot use a subclass without changing the VM. Are you sure you put the modified Semaphore class into SpecialObjectsArray after adding the inst var?
>>>>
>>>> - Bert -
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>