On 7 October 2011 23:38, Eliot Miranda <[email protected]> wrote: > > > On Fri, Oct 7, 2011 at 1:30 PM, Igor Stasenko <[email protected]> wrote: >> >> I don't understand why this problem appear only recently, and if i >> remember before i never heard that people >> had a problems with too many open sockets (and consequently exceeding >> a semaphore table space). >> >> Is there something we changed in language? in VM? or is it purely >> because we are lagging behind the scale of >> projects which today running on pharo? :) > > In the VM. In Cog I implemented a thread-safe non-blocking signal external > semaphore facility but I was too lazy to implement a thread-safe > non-blocking growing facility. It seems simple to set the size at start-up. > You choose a value large enough for your application, set it, save the > image and you're done. Whereas implementing a non-blocking growing facility > is tricky. >> Hmm, that confuses me even more.
In Squeak VM there is a single hard limit for SemaphoresToSignalA, and SemaphoresToSignalB tables - 500 (i dont remember correct name of these tables). In these tables, upon receiving a signal, it storing the index of semaphore to signal, when you using signalSemaphore() function. Then at interrupt time, these tables are flushed by signaling corresponding semaphores which are stored in external semaphore table under corresponding index. This means that between two interrupts you cannot signal more than 500 semaphores. And given that time between interrupts are pretty small (about 1 ms) i hardly beleive that you can put such high load on server to receive more than 500 signals in 1 ms time period. So the problem is not here, apparently, the problem is in size of external semaphore table , where semaphore objects are stored, which growth can be controlled completely by image size (this is a simple array), because signaling machinery operating only with indexes in this table but not with actual semaphores. Now, since i don't know well how much changes you did in signaling code in Cog. I only suspect that your conclusion that your changes might cause the problems are wrong. > > -- > best, > Eliot > -- Best regards, Igor Stasenko.
