Re: clone() <-> getpid() bug in 2.6?

[Davide Libenzi]

On Sun, 6 Jun 2004, Patrick J. LoPresti wrote:

> "Paul Rolland" <rol@xxxxxxxxxx> writes:
> 
> > Hello,
> > 
> > > It does that  for the unique  filenames and id stamps 
> > > (maildir format and
> > 
> > I though this was a job for mktemp and co.
> 
> Sure, if you want to create a unique filename on a local unshared
> disk.
> 
> But suppose you want a unique filename on a partition which might be
> NFS-mounted with multiple concurrent writers.  Oh, and the year is
> 1997.  Still want to use mktemp?
> 
> Bernstein decided to name each file:
> 
>     <time>.<PID>.<fully-qualified-domain-name>
> 
> This approach makes three assumptions.  First, that the time does not
> repeat.  Second, that the FQDN is unique.  Third, that the time
> changes (i.e., one second elapses) before a PID is reused on the local
> system.  Subject to these assumptions, this is a perfectly reliable,
> very efficient, lock-free way to create unique file names.

As long as 1) your program is not MT 2) your process creates exactly *one* 
unique file. Then yes, it is fine. But, if your program is MT (with 
threads sharing the PID) or your single thread process creates two (or 
more) unique files within 1 sec, you've got a problem. Using gettid() 
would solve the MT issue (there's still the tid recycling period), but not 
the time issue.



- Davide

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/