> IMHO it would be better to switch to poll/epoll from select instead of > fighting file descriptor numbers.
Sure, that's my opinion too. It's just some significant amount of work which looks like less prioritized at this moment than other application improvements. So I'm looking for some solution for the short term. Pavel On Fri, May 7, 2010 at 5:24 PM, Mikhail Terekhov <ter...@gmail.com> wrote: > On Fri, May 7, 2010 at 4:43 PM, Pavel Ivanov <paiva...@gmail.com> wrote: > >> Hi, all! >> >> I'm writing a server application that uses SQLite database as a >> storage. In fact for various reasons I use a lot of SQLite database >> files at once. This application can serve hundreds of clients spread >> all over the network. Communication with those clients goes over >> non-blocking sockets and currently select() is used to listen for >> events in those sockets. select() has limitation that it can be used >> only with file descriptors less than 1024. On a heavy loaded server my >> application can easily run out of those 1024 file descriptors which >> will mean that it will no longer accept connections from new clients. >> To avoid such situation or at least to make possibility of such event >> less I'd like to force SQLite to open databases with file descriptors >> greater than 1024. Is there a way how I can do that without patching >> SQLite sources and maintaining this patch over SQLite updates? >> >> > IMHO it would be better to switch to poll/epoll from select instead of > fighting file descriptor numbers. > > > Regards, > -- > Mikhail Terekhov > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
