I copied your comment to the issue thread. Maybe it is best to hold the conversation there as to leave a better trace.
> On 13 Oct 2021, at 13:29, Henrik Sperre Johansen > <henrik.s.johan...@veloxit.no> wrote: > > Seens it used to be in the «old» PharoVM before the reconcilliation: > https://forum.world.st/external-semaphores-again-tp4712934p4713396.html > > Maybe it’s still possible to find it in the git history of the current > pharovm repository? > > Cheers, > Henry > > On Wednesday, October 13, 2021, Sven Van Caekenberghe <s...@stfx.eu> wrote: > 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 > > <henrik.s.johan...@veloxit.no> 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 > >> <henrik.s.johan...@veloxit.no> 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 <s...@stfx.eu> 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 > >>> > >>> > >>> > >>>
