[22:45] <OvenWerks> Eickmeyer: interesting, open file->write file->close file->send dbus message that file has changed->process two accepts dbus message and reads the same file->process two gets a copy of the file as it was before it was written  :P
[22:46] <OvenWerks> wait 1 second (maybe less) before sending dbus signal and all is fine
[22:59] <Eickmeyer> I've seen a lot of that "wait 1 second" before doing x happening lately, seems in order to avoid race conditions a lot of the time.
[23:25] <OvenWerks> there is rather a lot done "before" the dbus signal is sent. A tempfile is created (the file will not read if it sees that file) then the config file is removed and the tempfile is moved to the config file (mv is atomic). If anything I would expect it to complain the file doesn't exist.
[23:27] <OvenWerks> however, the evidence concidered, I suspect the temp files existance does not make it to the file system in time even. I am guessing file system directories are cached somewhere.
[23:30] <OvenWerks> At least there is no way the read file can be zero bytes long anymore. And a wait a sec (actually studio-cmd is .5sec) is not a big deal.
[23:30] <OvenWerks> I am starting to understand why jackdbus was locking up if I don't add delays between commands