[Pharo-dev] external semaphores…again

phil at highoctane.be phil at highoctane.be
Wed Oct 9 02:21:58 EDT 2013


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 <siguctua at gmail.com> wrote:

>
>
>
> On 7 October 2013 18:01, Henrik Johansen <henrik.s.johansen at veloxit.no>wrote:
>
>>
>> On Oct 7, 2013, at 5:40 , Igor Stasenko <siguctua at gmail.com> wrote:
>>
>>
>>
>>
>> On 7 October 2013 17:25, Henrik Johansen <henrik.s.johansen at veloxit.no>wrote:
>>
>>>
>>> On Oct 7, 2013, at 4:36 , Igor Stasenko <siguctua at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131009/1247a288/attachment-0002.html>


More information about the Pharo-dev mailing list