[squeak-dev] Questions about external objects

Bert Freudenberg bert at freudenbergs.de
Fri Oct 24 18:44:00 UTC 2014

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.

- 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 -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141024/b8598773/smime.bin

More information about the Squeak-dev mailing list