Hi, On Friday 28 January 2011 15:25:01 Davidlohr Bueso wrote: > On Fri, 2011-01-28 at 15:12 +0100, Petr Uzel wrote: > > Hi, > > > > RFC: > > > > Sometimes, when there are multiple processes generating time-based > > UUIDs in a loop (each of them using multiple threads), it can happen > > that the socket backlog in uuidd daemon is full and so the connection > > request is refused. uuid_generate_time() then fallbacks to unsafe way of > > generating UUID, which may cause duplicate time-based UUIDs to be > > generated. > > Interesting catch. Could this not be resolved with a small pause > (nanosleep), avoiding the socket backlog? Not sure if it's best for a > library though. yes it would, but the number of parallel requests can be made higher than the hardcoded backlog value, which would lead to current behaviour or, if the sleep+daemon request is done in a loop, it can lead to unbound delay and the caller has no way to affect it. The options seem to be: * current state: try daemon otherwise call fallback * return -1 if not able to connect the daemon, and let the application decide what to do * loop until daemon socket is available, always returning a uuid alothough it may take unspecified time Then, the fallback parameter would rather mean 'daemon recovery mode'. dave -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
