On Oct 7, 2013, at 5:40 , Igor Stasenko <siguctua@gmail.com> wrote:




On 7 October 2013 17:25, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

On Oct 7, 2013, at 4:36 , Igor Stasenko <siguctua@gmail.com> wrote:

> 1 thing.
>
> can you tell me what given expression yields for your VM/image:
>
> Smalltalk vm maxExternalSemaphores
>
> (if it gives you number less than 10000000 then i think i know what is your problem :)
>

Uhm, I didn't read your implementation, but the proper thing to do for a VM which doesn't care about the external objects table (splObjs at: 39) growing, is returning nil from maxExternalSemaphores, like it will for pre-Cog VM's.

or.. release VM + image, where image aware of current VM capabilities, and refuses to run on older ones, and get rid of all this stuff altogether.

i changed the low-level implementation (C level), but not primitive level. sure thing more cleanup & polishing can be done,
but the changes i made never get reviewed and properly tested (though, there was no problems reported since year from when it was introduced,
except from last unfortunate rollback to Eliot's original implementation).

I know, which is why I thought you might like the feedback :P
AFAICT, it would be nice to couple the changes you made with changing parameterAt: 49 back to returning nil, as well as returning an error for parameterAt: 49 put: that the section is not in use/obsolete, instead of returning bogus values.

Though, sounds a bit strange how parameterAt: 49 can return a huge number without any changes to the related code (which would then still be reading from a 16bit field :P)
 
 
Otherwise, you'll get a domain error when you eventually (yes,yes, it'll take awhile) run out, and maxExternalSemaphoresSilently: tries to set the new max to a value that won't fit in the 16bit header field where it expects to put it�

yes.. theoretically.. but i have gut feeling that your image/setup will experience a lot of other different problems (memory consumption/amount of available OS handles etc), before you get to that point. And at that point, you will need to modify VM/OS/image anyways (or figure how to work around limits in other way)..
 

Yap, I guess you could say changing to a nil return would be more a change to play by established conventions when reporting capabilities/needs of the VM than anything with practical impact.

Cheers,
Henry