Le 25 mars 2013 à 20:12, Wietse Venema a écrit : > This patch implements the third solution that I described earlier: > use kqueue() for event handling, and use select() to enforce > read/write time limits. > > This code will attempt to handle descriptors >=FD_SETSIZE, by > dup()ing them down if possible. This will in practice eliminate the > FD_SETSIZE limit with Postfix daemons (these reserve some 100 low > file descriptors for third-party libraries that use select() > internally). > > Wietse > > [...patch code...]
Hello Wietse, Once again, many thanks for your contribution to this problem. I still have to carefully read your patch, so as to be sure to have tried to understand everything. ;-) But I believe to have understood it is kind of an "all or nothing" approach: either poll for everything, or select for everything. So, if you allow, I have a "theoretical" question. Let's consider a hypothetical OS capable to poll anything but devices. On the other hand, the bulk of operations in Postfix seems to be related to sockets, fifos... (but I may be wrong, of course). Aren't we sacrifying potential efficiency gains by having that OS making use of select exclusively? Back to our actual OS now. I suddenly remembered that /dev/random (or, equivalently in this case, /dev/urandom) doesn't need any special treatment: just read the wanted bytes from it, data should be immediately available, and the operation should return immediately. Should it not behave that way, I guess this would mean the kernel is stuck anyway (I may be wrong here too, of course). Axel
