October 2021 - Pharo-dev - lists.pharo.org

Re: [squeak-dev] [ANN] Fuel release 4.0.0

by Mariano Martinez Peck

Nice job Max!! Thanks for all your hard work! On Sun, Oct 31, 2021 at 8:42 AM Max Leske <maxleske(a)gmail.com> wrote: > Hi everyone. > > It's been quite a while since we've done any major work on Fuel, so we are > very excited to announce version 4.0.0 of Fuel today! > > Short-list of the most interesting things: > > - builder API > - support for talents and anonymous classes > - support for FullBlockClosure > - full serialization support by default (no more need to load > FuelMetalevel to serialize classes and methods) > - full serialization support for Squeak > > The complete release notes are over on GitHub: > https://theseion.github.io/Fuel/releases/4.0.0/. > > We hope that you'll like what we've done and we're excited to see, what > kind of magic you will do with it. > If you are using Fuel in a project, please let us know and we'll add it to > the list of projects on GitHub (good for us and you ;)). > > As always, please report any issues to > https://github.com/theseion/Fuel/issues and we'll try to help you out. > > Cheers, > Max (on behalf of the Fuel team) > > -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> Blog: https://marianopeck.wordpress.com/

Oct. 31, 2021

Re: [squeak-dev] [ANN] Fuel release 4.0.0

by David T. Lewis

Thanks for this update, I just installed in and am looking forward to using the new version. I have had good experiences using Fuel in Squeak and Pharo for passing complex objects through OSPipe between images. Dave On Sun, Oct 31, 2021 at 12:42:09PM +0100, Max Leske wrote: > Hi everyone. > > It's been quite a while since we've done any major work on Fuel, so we are very excited to announce version 4.0.0 of Fuel today! > > Short-list of the most interesting things: > - builder API > - support for talents and anonymous classes > - support for FullBlockClosure > - full serialization support by default (no more need to load FuelMetalevel to serialize classes and methods) > - full serialization support for Squeak > > > The complete release notes are over on GitHub: https://theseion.github.io/Fuel/releases/4.0.0/. > > > We hope that you'll like what we've done and we're excited to see, what kind of magic you will do with it. > If you are using Fuel in a project, please let us know and we'll add it to the list of projects on GitHub (good for us and you ;)). > > > As always, please report any issues to https://github.com/theseion/Fuel/issues and we'll try to help you out. > > > Cheers, > Max (on behalf of the Fuel team) >

Oct. 31, 2021

[ANN] Fuel release 4.0.0

by Max Leske

Hi everyone. It's been quite a while since we've done any major work on Fuel, so we are very excited to announce version 4.0.0 of Fuel today! Short-list of the most interesting things: - builder API - support for talents and anonymous classes - support for FullBlockClosure - full serialization support by default (no more need to load FuelMetalevel to serialize classes and methods) - full serialization support for Squeak The complete release notes are over on GitHub: https://theseion.github.io/Fuel/releases/4.0.0/. We hope that you'll like what we've done and we're excited to see, what kind of magic you will do with it. If you are using Fuel in a project, please let us know and we'll add it to the list of projects on GitHub (good for us and you ;)). As always, please report any issues to https://github.com/theseion/Fuel/issues and we'll try to help you out. Cheers, Max (on behalf of the Fuel team)

Oct. 31, 2021

Re: Hardening Zinc's Core HTTP Server

by Tim Mackinnon

Hey Sven - really appreciate your thorough approach to this, and itâs been interesting seeing the results (I did try a few script injection attempts but didnât get up to running burp suite on it, which I may try it while you have the instances). Kudos to Levente for taking a more reasoned approach and using inside knowledgeâ¦ this community is awesome! Tim > On 29 Oct 2021, at 19:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > ï»¿Here is yet another update: > > The instances > > - On Amazon AWS: http://34.245.183.130:1701 > > - On Microsoft Azure: http://51.137.72.94:8080 > > have now been running for 18+ days. > > Having observed the overall amounts of critical resources inside the Pharo images, things look good. > > Seaside WASSession cleanup goes slowly but does work over time. > > Eventually I will stop at least the Azure instance because it costs me personal money. > >> On 11 Oct 2021, at 19:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Here is an update on the status of both instances. >> >> A couple of people tried fiddling with invalid input which did result in exceptions, but everything was handled correctly so that the server kept on functioning. >> >> There were no spurious crashes. >> >> There was one attack by Levente Uzonyi that was successful though. >> >> He used the fact that Seaside sessions are long lived (cached for a certain time) combined with the fact that the Reddit.st app kept one GLORP database connection through P3 open to PostgreSQL and fired off a small denial of service (DOS) attack. Eventually either the VM ran out of space in the ExternalSemaphoreTable, making Socket creation, either for database connections or for handling new HTTP request impossible or the database's own connection limit was reached. At that point the HTTP server or the Pharo VM stopped functioning. >> >> Although Levente used a sequential number of requests, a concurrent number of request could cause similar problems (related, but differently). >> >> In looking at what he reported it also became clear that I accidentally left a debugging exception handler active, which is not good in a production image. >> >> Both instances are now redeployed with the following changes: >> >> - the Reddit.st code was changed to not keep the database connection open all the time, but instead connect/disconnect per request. this might be a bit slower, but it conserves resources much better and solves the original issue Levente reported >> >> https://github.com/svenvc/Reddit/commit/f2e0a0dc00b9cbb68cfa4fb007906365ae6… >> >> - a new feature was added to Zinc HTTP Components' ZnManagingMultiThreadedServer (the default) to enforce a maximum number of concurrent connections being allowed (the limit is 32 by default, but changeable if you know what you are doing). when the limit is reached, 503 Service Unavailable responses are sent to the excess clients and the connection is closed. this should help protect against concurrent connection DOS attacks >> >> https://github.com/svenvc/zinc/commit/ac0f06e74e7ab129610c466cb1d7ea9533d29… >> >> - the deploy script was changed to use the more primitive WAErrorHandler >> >> https://github.com/svenvc/Reddit/commit/874b631e6dc0c04c8c0b687ef770d00540d… >> >> Thanks again to Levente for taking the time to try an attack and for reporting it clearly. >> >> Sven >> >>>> On 29 Sep 2021, at 17:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Both instances have been up for 5 days now, looking for more testers. >>> >>>> On 23 Sep 2021, at 17:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> Hi, >>>> >>>> Zinc HTTP Components [https://github.com/svenvc/zinc] has been a part of Pharo since version 1.3 (2011). It is an open-source framework to deal with the HTTP networking protocol, modelling all aspects involved. It also offers both client and server functionality. >>>> >>>> The reliability of the code base has improved steadily over the years, thanks to virtually all Pharo developers using it, directly or indirectly. Over the summer a number of issues that popped up after Pharo 9 was released were resolved. >>>> >>>> The robustness of the core HTTP server is one important aspect. To put this quality further to the test, I deployed two servers with the same demo Seaside application, Reddit.st, open to the internet, without any further protections. >>>> >>>> - On Amazon AWS: http://34.245.183.130:1701 >>>> >>>> - On Microsoft Azure: http://51.137.72.94:8080 >>>> >>>> The application's source code can be found at [https://github.com/svenvc/Reddit] For the technically curious there are also deploy instructions at [https://github.com/svenvc/Reddit/blob/main/DEPLOY.md] The demo app itself is described in an older article [https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740] Note that, by definition, there is no HTTPS/TLS variant. >>>> >>>> If you manage to break this server with (a) malicious request(s) in such a way that you can explain what you did for others to confirm your approach, you not only help me/us improve the code, but earn eternal fame as well ;-) >>>> >>>> Sven >>>> >>>> PS: I hope I won't regret this, I am looking for constructive criticism. >>>> >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> Proudly supporting Pharo >>>> http://pharo.org >>>> http://association.pharo.org >>>> http://consortium.pharo.org >>>> >>> >>

Oct. 31, 2021

Re: Hardening Zinc's Core HTTP Server

by Sven Van Caekenberghe

Here is yet another update: The instances - On Amazon AWS: http://34.245.183.130:1701 - On Microsoft Azure: http://51.137.72.94:8080 have now been running for 18+ days. Having observed the overall amounts of critical resources inside the Pharo images, things look good. Seaside WASSession cleanup goes slowly but does work over time. Eventually I will stop at least the Azure instance because it costs me personal money. > On 11 Oct 2021, at 19:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Here is an update on the status of both instances. > > A couple of people tried fiddling with invalid input which did result in exceptions, but everything was handled correctly so that the server kept on functioning. > > There were no spurious crashes. > > There was one attack by Levente Uzonyi that was successful though. > > He used the fact that Seaside sessions are long lived (cached for a certain time) combined with the fact that the Reddit.st app kept one GLORP database connection through P3 open to PostgreSQL and fired off a small denial of service (DOS) attack. Eventually either the VM ran out of space in the ExternalSemaphoreTable, making Socket creation, either for database connections or for handling new HTTP request impossible or the database's own connection limit was reached. At that point the HTTP server or the Pharo VM stopped functioning. > > Although Levente used a sequential number of requests, a concurrent number of request could cause similar problems (related, but differently). > > In looking at what he reported it also became clear that I accidentally left a debugging exception handler active, which is not good in a production image. > > Both instances are now redeployed with the following changes: > > - the Reddit.st code was changed to not keep the database connection open all the time, but instead connect/disconnect per request. this might be a bit slower, but it conserves resources much better and solves the original issue Levente reported > > https://github.com/svenvc/Reddit/commit/f2e0a0dc00b9cbb68cfa4fb007906365ae6… > > - a new feature was added to Zinc HTTP Components' ZnManagingMultiThreadedServer (the default) to enforce a maximum number of concurrent connections being allowed (the limit is 32 by default, but changeable if you know what you are doing). when the limit is reached, 503 Service Unavailable responses are sent to the excess clients and the connection is closed. this should help protect against concurrent connection DOS attacks > > https://github.com/svenvc/zinc/commit/ac0f06e74e7ab129610c466cb1d7ea9533d29… > > - the deploy script was changed to use the more primitive WAErrorHandler > > https://github.com/svenvc/Reddit/commit/874b631e6dc0c04c8c0b687ef770d00540d… > > Thanks again to Levente for taking the time to try an attack and for reporting it clearly. > > Sven > >> On 29 Sep 2021, at 17:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Both instances have been up for 5 days now, looking for more testers. >> >>> On 23 Sep 2021, at 17:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi, >>> >>> Zinc HTTP Components [https://github.com/svenvc/zinc] has been a part of Pharo since version 1.3 (2011). It is an open-source framework to deal with the HTTP networking protocol, modelling all aspects involved. It also offers both client and server functionality. >>> >>> The reliability of the code base has improved steadily over the years, thanks to virtually all Pharo developers using it, directly or indirectly. Over the summer a number of issues that popped up after Pharo 9 was released were resolved. >>> >>> The robustness of the core HTTP server is one important aspect. To put this quality further to the test, I deployed two servers with the same demo Seaside application, Reddit.st, open to the internet, without any further protections. >>> >>> - On Amazon AWS: http://34.245.183.130:1701 >>> >>> - On Microsoft Azure: http://51.137.72.94:8080 >>> >>> The application's source code can be found at [https://github.com/svenvc/Reddit] For the technically curious there are also deploy instructions at [https://github.com/svenvc/Reddit/blob/main/DEPLOY.md] The demo app itself is described in an older article [https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740] Note that, by definition, there is no HTTPS/TLS variant. >>> >>> If you manage to break this server with (a) malicious request(s) in such a way that you can explain what you did for others to confirm your approach, you not only help me/us improve the code, but earn eternal fame as well ;-) >>> >>> Sven >>> >>> PS: I hope I won't regret this, I am looking for constructive criticism. >>> >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >> >

Oct. 29, 2021

This week (43/2021) on the Pharo Issue Tracker

by Marcus Denker

We merged 8 PRs and closed 9 issues. There are 11 more PRs ready, just missing a review: https://github.com/pharo-project/pharo/pulls Features ======= - [Pharo 10] Reactivating debugger opening strategies by default. #10271 https://github.com/pharo-project/pharo/pull/10271 Fixes ===== - 10204-RBMoveMethodRefactoring-incorrectly-computes-types-when-using-a-class-name-for-the-variable-to-move-into #10266 https://github.com/pharo-project/pharo/pull/10266 Speed ===== - speedup-specialSelectorIndexOrNil #10277 https://github.com/pharo-project/pharo/pull/10277 Cleanups ======== - Cleanup Beacon #10281 https://github.com/pharo-project/pharo/pull/10281 - Cleanup-Merge-FullBlockClosure1 #10272 https://github.com/pharo-project/pharo/pull/10272 - 10274-Cleanup-cleanup-IRBytecodeGeneratorv3VMHeader #10275 https://github.com/pharo-project/pharo/pull/10275 - 10231-Cleanup-check-references-to-EncoderForSistaV1 #10243 https://github.com/pharo-project/pharo/pull/10243

Oct. 29, 2021

This week (42/2021) on the Pharo Issue Tracker

by Marcus Denker

We merged 34 PRs and closed 35 issues. Literal Sharing =============== Since Pharo9, literals are compiled as read-only objects. This used to be a source of ugly bugs (code accidentally changing a literal, but the source not showing it). As we now can not change literals, and identity changes anyway on recompile, we are free to unify literals over the whole image. This seems to save ~2MB with the current build. We do this once as part of the build, users with large code bases can re-run it (see ImageCleaner>>#shareLiterals) and save some space. - Enable-SharedLiterals #10186 https://github.com/pharo-project/pharo/pull/10186 - 10190-Literal-Sharing-unify-nested-arrays #10195 https://github.com/pharo-project/pharo/pull/10195 Speed ===== - Use-equivalentTo-ReEquivalentSuperclassMethodsRule #10183 https://github.com/pharo-project/pharo/pull/10183 Features ======== - 10200-add-isClassSide-to-CompiledMethod #10202 https://github.com/pharo-project/pharo/pull/10202 - 4211 easy support for equality and hash with nice default behavior #4803 https://github.com/pharo-project/pharo/pull/4803 - Migrating RBInlineMethodRefactoring into Refactoring2 #10163 https://github.com/pharo-project/pharo/pull/10163 - Parameter refactoring migrations #10162 https://github.com/pharo-project/pharo/pull/10162 Class Parser ============ Work continous on the class parser / fluid class definitions - Changing uses: and trait: to use traits: in the class definition. #10199 https://github.com/pharo-project/pharo/pull/10199 - Removing #<< from SequentialCollection class #10197 https://github.com/pharo-project/pharo/pull/10197 Fixes ===== - Autofixes on class side raise DNU #10235 https://github.com/pharo-project/pharo/pull/10235 - fix: #10211 addSearch: -> addRule: adding two little tests to start #10220 https://github.com/pharo-project/pharo/pull/10220 - 9973-Different-behavior-in-Playground-for-deprecated-method-transformed-vs-nontransformed-deprecations #10222 https://github.com/pharo-project/pharo/pull/10222 - [P10] 8170-Pharo-image-freeze-on-Windows-after-some-hours-Idle-P10 #10188 https://github.com/pharo-project/pharo/pull/10188 - 10193-testNoEquivalentSuperclassMethods-failing-on-ci #10194 https://github.com/pharo-project/pharo/pull/10194 Cleanup - Old Blocks / Bytecode =============================== Cleaning the core system and compiler - 9929-Reflectivity-compiler-still-uses-pushClosureCopyCopiedValuesargsjumpTo #10177 https://github.com/pharo-project/pharo/pull/10177 - Cleanup-FullBlocks: remove dead code #10221 https://github.com/pharo-project/pharo/pull/10221 - Cleanup-optionFullBlockClosure #10229 https://github.com/pharo-project/pharo/pull/10229 - Remove-EncoderForV3PlusClosures #10181 https://github.com/pharo-project/pharo/pull/10181 - Fix 10178: Cleanup OldBlocks Compiler/Decompiler #10180 https://github.com/pharo-project/pharo/pull/10180 Cleanup ======= - Cleanup-Deprecated9-More #10236 https://github.com/pharo-project/pharo/pull/10236 - Release test to ensure we have no protocol names with leading or trailing spaces #10233 https://github.com/pharo-project/pharo/pull/10233 - Mark a few abstract refactorings #10246 https://github.com/pharo-project/pharo/pull/10246 - Mark abstract classes in Ring #10250 https://github.com/pharo-project/pharo/pull/10250 - "Tools-Test" package should be "Tools-Tests" #10244 https://github.com/pharo-project/pharo/pull/10244 - Fix lint in Array>>#copyWithDependent: #10252 https://github.com/pharo-project/pharo/pull/10252 - Cleanup: no leading or trailing space in method category name #10230 https://github.com/pharo-project/pharo/pull/10230 - 10205-LiteralVariable-classcheckValidName-has-commented-out-code #10207 https://github.com/pharo-project/pharo/pull/10207 - Remove empty protocols in ZnStaticFileServerDelegate #10224 https://github.com/pharo-project/pharo/pull/10224 - Cleanup-hasLinks #10206 https://github.com/pharo-project/pharo/pull/10206 - 10191-MCClassDefinitionring2LayoutType-misses-Double-layouts #10192 https://github.com/pharo-project/pharo/pull/10192 - Fix a few lints regarding categorization of "converting" #10175 https://github.com/pharo-project/pharo/pull/10175 - Adopte testNoUncategorizedMethods #10169 https://github.com/pharo-project/pharo/pull/10169 Pharo9 ====== [P9] 8170-Pharo-image-freeze-on-Windows-after-some-hours-Idle #10179 https://github.com/pharo-project/pharo/pull/10179

Oct. 22, 2021

Book the dates: Pharo Days 2021: 3/4 March 2022 @ Lille

by stephane ducasse

Dear Pharoers We are super excited to announce the dates of the next Pharo Days. Pharo Days 2021 will be held at Lille 3/4 March 2022 We will set soon a program and a website. Stay tuned. S.

Oct. 22, 2021

This week (41/2021) on the Pharo Issue Tracker

by Marcus Denker

We merged 25 Pull Requests and closed 13 Issue tracker entries Pharo 9 ======== - [P9] backporting-new-iceberg #10176 https://github.com/pharo-project/pharo/pull/10176 - enabling-debug-window-in-windows-P9 #10129 https://github.com/pharo-project/pharo/pull/10129 - [P9] 10085-Pharo-does-not-work-on-network-drive-on-Windows #10137 https://github.com/pharo-project/pharo/pull/10137 - P9-Backport-PR10099: Added two missing methods #tfPointerAddress #10146 https://github.com/pharo-project/pharo/pull/10146 - 10147-Fix-invalid-non-Boolean-return-when-CPU-watcher-is-enabled-For-P9--P10 #10148 https://github.com/pharo-project/pharo/pull/10148 - 10152-Backport-Pharo9-10113-speedup-isReferenced-for-ClassVariables-from-a-Pool- #10157 https://github.com/pharo-project/pharo/pull/10157 Pharo 8 ======= - Fix invalid (non-Boolean) return when CPU watcher is enabled #10134 https://github.com/pharo-project/pharo/pull/10134 Fixes ===== - 10085-Pharo-does-not-work-on-network-drive-on-Windows-P10 #10138 https://github.com/pharo-project/pharo/pull/10138 - 10144-SystemNavigationobsoleteClasses-should-use-isObsolete #10145 https://github.com/pharo-project/pharo/pull/10145 - Fix InstructionStream>>nextPc: #10044 https://github.com/pharo-project/pharo/pull/10044 - [P10] 10147-Fix-invalid-non-Boolean-return-when-CPU-watcher-is-enabled-For-P9--P10 #10149 https://github.com/pharo-project/pharo/pull/10149 Features ======= - Provide autofix rule to have no unreferenced ivars left #10126 https://github.com/pharo-project/pharo/pull/10126 - enabling-debug-window-in-windows-P10 #10130 https://github.com/pharo-project/pharo/pull/10130 - Provide Autofix for ReProperMethodProtocolNameRule #10140 https://github.com/pharo-project/pharo/pull/10140 Speed ====== - 10113-speedup-isReferenced-for-ClassVariables-from-a-Pool #10151 https://github.com/pharo-project/pharo/pull/10151 Cleanup ======= - Cleanup-theNonMetaParentName #10118 https://github.com/pharo-project/pharo/pull/10118 - Cleanup package Refactoring-Changes #10142 https://github.com/pharo-project/pharo/pull/10142 - Improve naming in ProtocolConventionTest #10132 https://github.com/pharo-project/pharo/pull/10132 - Cleanup-defaultTimeLimit #10153 https://github.com/pharo-project/pharo/pull/10153 - clean-dirty-packages-from-repo #10154 https://github.com/pharo-project/pharo/pull/10154 - Debugger infrastructure improvement and cleaning #10133 https://github.com/pharo-project/pharo/pull/10133 - Protocol for all class side methods #reset changed to initialization #9999 https://github.com/pharo-project/pharo/pull/9999 - Refactoring2-Cleanup-parentSuchAs #10158 https://github.com/pharo-project/pharo/pull/10158 - Ring-Cleanup-theNonMetaClass #10161 https://github.com/pharo-project/pharo/pull/10161 - 10065-Cleanup-ClassBuilder-remove-uses #10160 https://github.com/pharo-project/pharo/pull/10160

Oct. 15, 2021

Re: Something weird in VirtualMachine>>#maxExternalSemaphores:

by Sven Van Caekenberghe

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.johansen(a)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 <sven(a)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.johansen(a)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-Virtua… > > > > 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.johansen(a)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 <sven(a)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 > >>> > >>> > >>> > >>>

Oct. 13, 2021