Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!jerry From: jerry@olivey.ATC.Olivetti.Com (Jerry Aguirre) Newsgroups: news.software.b Subject: Re: Ideas for Message-ID's Message-ID: <50580@olivea.atc.olivetti.com> Date: 30 Mar 91 06:54:56 GMT References: <1991Mar22.050749.22115@looking.on.ca> <1991Mar29.032900.548@ni.umd.edu> Sender: news@olivea.atc.olivetti.com Organization: Olivetti ATC; Cupertino, CA Lines: 16 In article <1991Mar29.032900.548@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >You might just dispense with the process id completely, and use a >unique time value composed of the time (though in that case, you've >got 64 bits 'o time, 32 each in tv_sec and tv_usec in struct timeval). What! Trade 15 bits of PID for 32 bits of tv_usec? :-) Actually the tv_usec doesn't use all 32 bits, only 20. It only counts to 999,999. Even if it was bigger the correct action would be to scale the excess into the seconds. If one encoded it as , with the usec as variable width field, then one could get smaller message IDs by just looping on gettimeofday until the usec. returned is a small value. Delaying some postings a fraction of a second to save the world from having to handle bigger message-IDs. :-)