> (2) If we are to allow random PIDs, then on a moderately busy system, PID
> re-use (within a short amount of time) is going to occur, and a highly
> loaded really busy systems its going to occur fairly often....
It's only when it happens in less than 1 second that it's an issue. Last
I checked even Linux can't fork 16k times per second. But next year or
the year after that's not an unreasonable figure given hardware and
software improvements.
> (3) Any user-space code this breaks I guess can be considered broken and
> will probably have to be fixed....
>
> Now this probably includes Apache - but since this situation can occur
> under OpenBSD which presumably apache runs under, a work around has to
> be found anyhow.
Apache is not broken by this at all... mod_unique_id will be less
reliable, but it has enough other crud thrown into the magic unique id
that it's still unlikely to generate overlapping "unique" ids. There's
even crud in there to try to defeat time warps. And if someone really
doesn't trust that the other magic is enough they're free to write their
own mod_unique_id which uses atomic_inc() on shared memory... I just chose
not to do that 'cause I wanted something that would compile essentially
everywhere.
> And programs that generate message IDs, etc (and Dean Gaudlet pointed)
> out by doing "time() concat getpid()" will also have to be fixed. I'm
> not sure how many things will be affected by this, but its broken
> anyhow.
>
> (Perhaps, and its probably a bit far-fetched, but as the net grows, the
> odds on a non-deliberate collision are increasing all the time,
> especially if the algorithm only uses the hostname and not the fqdn).
Er well those programs do use more magic than just time() concat getpid(),
but time() concat getpid() is the only part of the magic that is used to
distinguish indentifiers on a single system. Generating universally
unique tokens is a real challenge. Message-id collision is not that
abnormal (which is one reason I don't trust it for duplicate message
elimination, but that's off-topic).
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu