802 copies of dccm running

Gary Mills mills@cc.umanitoba.ca
Thu Jan 4 01:36:51 UTC 2007


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-



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.