On Thu, 2007-08-30 at 10:08 +0200, Peter J. Holzer wrote: > On 2007-08-29 18:36:12 -0400, Guy Hulbert wrote: [snip] > > Just assume that time() can have the granularity of the CPU instruction > > counter[1]. > > It could (if your perl implementation uses 128 bit long doubles), but it
Or you could have gettimeofday return 3 ints (sec, nano-sec, atto-sec) instead of 2. > isn't guaranteed to have that. You have to plan for the worst case and > that's probably a 60 Hz counter. Or you can just warn that the transaction ID may be broken on some systems. Does it provide some critical internal function or is it just for logging ? Or we can provide some alternate hack. > > Here are some (measured) resolutions of gettimeofday on various systems: > > Linux/i386: 1 ms > Linux/SPARC: 2 ms > HP-UX/PA-RISC: 2 ms > Linux/Alpha: 976 ms (1024 Hz) 'ms' is usually milli-seconds but it appears you mean micro-seconds ( I pretend that u=mu and write it 'us' ). The alpha is a problem then. However, Time::HiRes seems to be over 10 years old ... are the alpha boxes still being sold ? [snip] > > However, with a 16 bit PID and 65K processors you might run > > into collisions with the PID ... > > I don't know see that follows. The PID still has to be unique at any > particular time. If a system can run more than 32k processes in parallel > it must use a 32 bit PID. Doh. Yeah, iirc it's been 32 bits on AIX since 1992. [snip] > > but I doubt anyone has a connection machine to run qpsmtpd on. > > > > I think time() + PID is sufficient "for now" ... unless threads share > > the PID ... > > They do on most systems - but you could use the TID instead of the PID. Yup. > > > ( otoh, qpsmtpd is not even threaded is it ? ). > > It might be possible to run Apache::Qpsmtpd on a multithreaded Apache. Unlikely. PHP people still won't bless mt apache. Postgres people discovered a problem with crypt() - from libc - you must not use crypt() passwords with Pg on mt apache (the problem is only seen with very high loads though). > > hp -- --gh
