Report progress of DASD formatting to the D-Bus interface #476
Conversation
ancorgs
force-pushed
the
dasd_progress2
branch
2 times, most recently
from
6fbc316
to
ead54a4
Compare
ancorgs
force-pushed
the
dasd_progress2
branch
3 times, most recently
from
4b370df
to
aa9e86b
Compare
|
There was a problem hiding this comment.
Omitting the PropertiesChanged signal would indeed confuse caching clients like cockpit.dbus, but we'll fix that with EmitsChangedSignal
| job = nil | ||
| progress = proc { |statuses| job.update_format(statuses) } | ||
| finish = proc { |result| job.finish_format(result) } | ||
| initial_statuses = dasd_backend.format(dasds, on_progress: progress, on_finish: finish) |
There was a problem hiding this comment.
This method eventually spawns a thread.
race Yay ! conditions
Besides the job initialization race visible in this method,
there are more serious races in ruby-dbus usage: the above callbacks will use the bus connection at a random time point, racing the main thread for protocol data on the D-Bus socket.
There was a problem hiding this comment.
Hmm, the methods in the thread only send signals, meaning that they only write to the D-Bus socket. Maybe that is less prone to races than reading.
Anyway, here is an old branch from 2010 when I got a multithreading patch and failed to make it work mvidner/ruby-dbus@master...multithreading
There was a problem hiding this comment.
Besides the
jobinitialization race visible in this method
As commented above, I considered it to be safe enough. Although we can rework the D-Bus API to make it even safer by creating the job object in advance. That would imply we also create Job D-Bus objects for processes that fail to start (the case now reported with the exit code 2). So there will be only two exit codes, 1 for wrong list of paths and 0 for process started, even if that process failed immediately.
there are more serious races in ruby-dbus usage
That's something I wouldn't know how to minimize or avoid.
There was a problem hiding this comment.
mvidner/ruby-dbus#73 is a basic demonstration of the way it fails
There was a problem hiding this comment.
mvidner/ruby-dbus#128 is good enough for signals
Co-authored-by: Martin Vidner <mvidner@suse.cz>
Problem
#464 implemented a D-Bus API for managing DASDs, but a way to track the progress of the formatting progress was still missing.
Solution
This adds the concept of storage jobs, that are exported at
/org/opensuse/DInstaller/Storage1/jobs/[0-9]+Every time a formatting operation starts properly, the path of a new job is returned. That job can be used to track the formatting status of all the DASDs involved in the operation.
Testing
Documentation
doc/dbus_api.md