[Christian Magnusson] > Right now we seldom have more than 1 connecting request in the listen-queue > at a time... mostly since the code _very_ quickly accepts all connections > and removes them from the queue. I'm sure nobody would notice any difference > if the listen-queue was lowered from 10 to 1 in the current source.
Concurrent connecting requests aren't necessarily unthinkable. If they depend on a user typing on a keyboard, true, but it's likely that requests depend on some common synchronisation, such as a timer with a fixed resolution, cron, etc. Perhaps it's also somewhat OS dependent. My program which breaks owserver uses a timer with a 1 second resolution, so while there might be several seconds between requests, there might be 2, 3 or 10 requests at a time. I've also noticed that it does only seem to break owserver on the local host, not on remote hosts, which could suggest that the network jitter could play a role. So I tried to have the requests "break steps" making it much less likely that several requests are fired off simultaniously (within the same microsecond). It didn't make owserver less likely to crash. It did, however, seem to reduce the problem that OW_get on some values suddenly no longer returns until owserver is restarted. -- Steinar ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
