On Fri, 2011-01-28 at 15:57 +0100, David Sterba wrote: > 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. Yeah, that was exactly my concern with the delay. > > 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 Both of these make a lot of sense. > * loop until daemon socket is available, always returning a uuid alothough it > may take unspecified time Not too sure about this one. > > Then, the fallback parameter would rather mean 'daemon recovery mode'. > > dave > Thanks, Davidlohr -- 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
