On Sat, Oct 8, 2011 at 12:13 PM, Igor Stasenko <[email protected]> wrote:
> 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. > That's not quite how it works. Each location in the VM's table maps to one semaphore in the image (each location remembers the number of signals to send to each external semaphore). So it's not the number of signals, it's the number of external semaphores in use. 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. > Could be. In any case, a command-line parameter does not harm :) > > > > > -- > > best, > > Eliot > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot
