Re: hash_queue_depth for better performance

From: Wietse Venema (no email)
Date: Sat Oct 27 2001 - 10:47:31 EDT


Claus Assmann:
> > > > I would like to stand corrected. How does sendmail cope with jumping
> > > > clocks?
> > >
> > > If the file exists sendmail won't use it. The chance for collisions
> > > is very small.
> >
> > Does Sendmail support multi-directory queues? If so, how does
>
> Yes.
>
> > Sendmail find out if a file name is already in use somewhere?
> > This requires a guaranted unique name, not just O_CREAT|O_EXCL.
>
> Why? It's sufficient if the name is unique inside a directory.
> sendmail doesn't move queue files around.

Aha. This is a subtle but important requirement.

Wasn't Sendmail going to split the queue into new mail and delayed
mail? If that ever happens, Sendmail would be moving mail from one
directory to another, and then file name collisions due to jumping
clocks will be hard to detect.

> > How does one prevent a random PID number generator from producing
> > the same number twice in a second without keeping a lot of state
> > information somewhere? Machines get faster all the time. Creating
> > 1000 processes/second is already possible on todays equipment.
>
> As I said: it's simple: you keep the process around for one second.

Aack! Pffhht! :-)

> It's certainly not nice, but it works (for now, a future version
> will take care of this).

I feel the pain. Perhaps Sendmail can maintain its own pseudo PID
counter; it's something that I have considered doing myself, and
it is practical as long as there is one parent process from which
all the others are spawned.

        Wietse
-
To unsubscribe, send mail to with content
(not subject): unsubscribe postfix-users








Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD