Just a note: in a Pharo20, the number is 256, no matter if in OSX or Windows (8 here).
In Pharo30 with vmLatest I get the Smalltalk vm maxExternalSemaphores 10000000 indeed. Phil On Tue, Oct 8, 2013 at 11:15 AM, Igor Stasenko <siguc...@gmail.com> wrote: > > > > On 7 October 2013 18:01, Henrik Johansen <henrik.s.johan...@veloxit.no>wrote: > >> >> On Oct 7, 2013, at 5:40 , Igor Stasenko <siguc...@gmail.com> wrote: >> >> >> >> >> On 7 October 2013 17:25, Henrik Johansen <henrik.s.johan...@veloxit.no>wrote: >> >>> >>> On Oct 7, 2013, at 4:36 , Igor Stasenko <siguc...@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. >> >> i agree. i will create a bug entry for it then.. > > >> >> Cheers, >> Henry >> > > > > -- > Best regards, > Igor Stasenko. >
