Hi Henry, Thanks for your reply.
I created an issue: https://github.com/pharo-project/pharo/issues/10156 Can we still find the file 'sqExternalSemaphores.c' from the old emails ? Sven > On 12 Oct 2021, at 19:20, Henrik Sperre Johansen > <[email protected]> wrote: > > I believe Igor Stasenko made changes so signals could no longer get lost, but > I’m not sure it ever got integrated in Cog… > > https://forum.world.st/Issue-5965-in-pharo-Can-t-allocate-semaphores-VirtualMachine-maxExternalSemaphores-aSize-Not-enough--tp4631607p4632388.html > > Maybe worth revisiting/reviewing? > If it works, the limitation would be gone, and the image warnings could be > removed with no ill side-effects. > > Cheers, > Henry > >> On 12 Oct 2021, at 18:55, Henrik Sperre Johansen >> <[email protected]> wrote: >> >> Hi Sven - you’re correct the main intent was to make it clear one should >> not really be setting this from the image during runtime - and make it as >> obvious as possible when it had. >> >> The way I remember it, the Error was only raised if the image is in >> development mode - so a developer running into this, would have the limit >> raised, but also get a debugger (which is hard to ignore) explaining the >> issue, while in runtime mode, the SystemNotification would get handled by >> logging so it would at least be possible to spot that it had happened. >> >> If there’s a less confusing way to achieve that it would be a good thing, >> but I’m not sure removing all warnings would be the best way, as the related >> i/o problems would be nearly impossible to determine the root cause of. >> >> Why forked? No idea/can’t remember… >> >> Cheers, >> Henry >> >>> On 12 Oct 2021, at 16:01, Sven Van Caekenberghe <[email protected]> wrote: >>> >>> Hi, >>> >>> The ExternalSemaphoreTable is an important resource since it holds 3 >>> Semaphores per Socket (network connection). The size of >>> ExternalSemaphoreTable determines how many such resources can be used >>> concurrently. >>> >>> VM parameter 49 holds this limit, it is accessed by >>> VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be >>> 256 currently. >>> >>> There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can >>> be used to set this limit higher. This seems to work. >>> >>> Now, there are some limitations here: the number must be a power of 2, >>> higher that the one set before and lower than 64K. BTW the number of file >>> descriptors for files and sockets is also limited by the OS for its >>> processes. >>> >>> Also, while growing the table, the Semaphores become unavailable to the VM >>> for a very short period of time, so they could miss signals, leading to IO >>> issues. >>> >>> For this reason, it seems that the design goal was to not allow this to >>> grow during normal use, only during startup or upfront configuration. >>> >>> Now comes the weird thing: the implementation/code of >>> VirtualMachine>>#maxExternalSemaphores: >>> >>> This is the method called when the current table is too small and when it >>> wants to grow larger than the current >>> VirtualMachine>>#maxExternalSemaphores. >>> >>> The implementation calls #maxExternalSemaphoresSilently: in a forked >>> thread, after signalling a SystemNotification with a full explanation. But >>> why should this be forked in the first place ? >>> >>> Then in the main thread, it signals an error ! Presumably because the >>> design goals mentioned before. >>> >>> These two actions are in conflict. >>> >>> All this is probably the result of well meant evolution and refactoring, >>> but it is quite confusing. >>> >>> My first idea would be: let the caller raise the error and don't try >>> raising the limit, remove the current implementation and replace it by what >>> is now #maxExternalSemaphoresSilently: >>> >>> What do you think ? >>> >>> Sven >>> >>> >>> >>>
