I mentioned a few days ago that I was waiting for a busy e-mail day to see how many `dccm' processes there would be, now that I've set `no-body' and `no-MX' within DNSBL_ARGS in dcc_conf. I'm pleased to report that, on a moderately busy day today, the count only rose to 17. It's dropped to 13 now.
On Tue, Jan 02, 2007 at 08:23:26PM -0700, Vernon Schryver wrote: > > From: Gary Mills > > > Surely the parent must know which children are busy and which > > are idle. Can't the parent just pick the first idle one? > > There are perhaps subtle implementation problems related to speed, > correctness, and robustness with having the parent know the state > of all children. > > However, there is a bigger problem with that model that you in particular > should care about. For the parent to be able to send to an individual > child and so with a private channel, the parent would need to devote a > file descriptor to each child. Since every mail message being processed > by dccd might need a DNSBL lookup simultaneously, that additional use > of file descriptors would reduce the -j limit on concurrent dccm jobs. > The current scheme uses no additional file descriptors because talking > to the DNSBL child is done with the socket normally used to talk to the > DCC server. Yes, you would need either a file descriptor or a UDP port for each helper. File descriptors are not that big a problem, as long as there isn't a leak. > > My system call trace is puzzling. When a helper is in its poll/recvfrom > > loop, poll() claims that one file descriptor is ready for reading, but > > recvfrom() says there's nothing there. I don't know how that's even > > possible. What could cause that behavior? > > - All of the idle children are asleep in select/poll waiting for > something to happen on either the pipe that tells them that the > parent has died or socket on which requests arrive. > > - A request arrives on the file descripter, so the kernel awakens > all of the idle children. > > - One child gets into the recvfrom() system call first, receives the > request, and starts working. > > - The thundering herd of other idlers get "sorry no data" from > recvfrom() on the non-blocking socket and go back to sleep. Ah, I had no idea that they were all listening on a shared socket. I didn't even know that that was possible. I'd assumed I was seeing a kernel bug. -- -Gary Mills- -Unix Support- -U of M Academic Computing and Networking- _______________________________________________ DCC mailing list [email protected] http://www.rhyolite.com/mailman/listinfo/dcc
