I do not understand. We fixed the problem reported by chris. So is there something else?
Stef On Jul 6, 2011, at 11:19 AM, Henrik Johansen wrote: > > On Jul 6, 2011, at 10:54 33AM, Sven Van Caekenberghe wrote: > >> >> On 06 Jul 2011, at 10:40, Janko Mivšek wrote: >> >>> If I recall others have also problems with sockets in Pharo, so here is >>> the my current image, which: >>> >>> - has 105 Sockets open, mostly waiting >>> - has also >105 processes open >>> - consumes 100% cpu >>> - on aSocket close responds with primitive failure >>> - image is workable, I can browse etc. >>> >>> - Pharo1.2.2a on Linux >>> >>> Sockets are waiting on Socket>>waitForConnectionFor:ifTimeOut: >> >> Is that number of open sockets and processes by design or not ? If they keep >> coming back, you must be creating them. Your application has to keep these >> (expensive) resources under control to start with. >> >> Long running Seaside images seem to be fine and they are using sockets and >> processes a lot. >> >> Socket have #close and #destroy, there might be a difference. >> >> I think that part of the cleanup of sockets is delayed (using finalization) >> and needs some GC work to complete. GC policies might be involved as well as >> weak datastructures. >> >> I am also interested in knowning the practical upper bound for open sockets >> and number of processes. >> >> Sven > > http://forum.world.st/Networking-change-in-Pharo-1-2-tp3456097p3461723.html > should explain it. > > TLDR; Changes in the image are required to work with Cog without silently > failing to signal semaphores when too many Sockets are open. > > Cheers, > Henry
