On Sun, 2014-09-28 at 14:04 -0600, Glenn Golden wrote: > Tanu Kaskinen <tanu.kaskinen at linux.intel.com> [2014-09-28 11:38:51 +0300]: > > On Sat, 2014-09-27 at 10:00 -0600, Glenn Golden wrote: > > > Why is it _creating_ a new runtime dir /tmp/pulse-XXXX (and associated > > > symlink in ~/.config/pulse) when it seems like what it ought to be doing > > > in this situation is simply looking for an extant runtime dir (given > > > that autospawn is disabled)? > > > > The function for getting the runtime dir also creates it if it doesn't > > exist. I don't think that's a good idea, but that's how Lennart did it > > in the beginning of time and nobody has bothered to changed it. > > > > OK. Should I file a ticket on that, just for completeness sake? I mean, just > as a reminder of something to look into at some future time when scraping out > or refactoring the code. Creatin the dir seems like wacky behavior in the > context of what is trying to be accomplished. Yes, a bug report in bugzilla would be nice to have. > > > What information participates in the hashing that generates the XXXX? > > > (The reason for this question is that it seems to generate identical XXXX > > > every time, if one starts with the initial conditions described above.) > > > > It's not a hash, it's a pseudo-random string. It seems that the seed > > isn't set by libpulse, it's only set by the daemon, so if a client > > creates the "random" directory, it will always be the same, because the > > seed will always be 1 (we use rand() for randomness). > > > > Ok. But this begs the question: If the seed is fixed, then what advantage > derives from naming the dir based on the k-th iterate of rand(), rather than > simply the value k itself (chosen from some suitably zero-padded sequence, > e.g. pulse-00001, pulse-00002, etc)? The latter would even have the > (admittedly minor) advantage of informing the user (and maintainer/debugger) > as to time ordering of the runtime directory creations. > > Actually, now that I think about it... the use of a fixed initial seed per > PA daemon brings up another even more interesting question: Since multiple > (distinct) users can run independent PA daemons (as long as each daemon talks > to disjoint subsets of the available audio hardware) then how do runtime > directories named like /tmp/pulse-XXXX get forcibly orthogonalized from user > to user, given that each daemon begins with rand() seed = 1? > > This question probably misses something glaringly obvious... I didn't explain clearly enough, so you misunderstood. The daemon doesn't use seed value 1, the daemon uses /dev/urandom as the seed. It's only the clients that use seed value 1, because that's the default value that rand() uses if srand() is not called first, and clients never call srand(), only the daemon does. /tmp/pulse-XXXX is deterministic only if it's created by a client. -- Tanu
