Hi, to keep the list updated on this: It turns out that GnuGk's LARGE_FDSET hack broke with changes in GNU Libc a while ago. I have re-written the implementation to use the poll() system call instead of select() so we don't need any hack to get around the 1024 socket limit of select() and don't have to patch libc system headers. The new implementation is on Github now for testing. Please note that the compile switch changed slightly. Use ./configure --enable-large-fdset No need to specify a maximum number of sockets any more. Just make sure the OS gives the process enough sockets and stack space (eg. "ulimit -n 10240 -s unlimited" on Linux). The new implementation should work on all OS that GnuGk supports, Linux, *BSD, MacOS X, Solaris, even on Windows. Please give it a test and report back how many concurrent calls you were able to have on a single server. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan@xxxxxxxxxxxxxx Website: https://www.gnugk.org Support: https://www.willamowius.com/gnugk-support.html Relaxed Communications GmbH Frahmredder 91, 22393 Hamburg, Germany Geschäftsführer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584 Tomoyuki Yokoo wrote: > Hi Jan, > > Thank you for your advice. > I will try stacktrace. > > Regards, > Yokoo > > > On 2018/12/10 16:29, Jan Willamowius wrote: > > Hi Yokoo, > > > > GnuGk should be able to handle way more than concurrent 123 calls when > > given enough resources. There is no built-in limit to the number of > > calls. And even when it runs out of file descriptors it shouldn't > > crash (just give an error message as in your first trace snippet). > > > > I would suggest to look at the stacktrace where in the code it crashed. > > > > Regards, > > Jan _______________________________________________________ Posting: mailto:gnugk-users@xxxxxxxxxxxxxxx Archive: https://lists.gnugk.org/pipermail/gnugk-users/ Unsubscribe: https://lists.gnugk.org/lists/listinfo/gnugk-users Homepage: https://www.gnugk.org/
