Questions on the new KIO::FileJob API
Allan Sandfeld Jensen
kde at carewolf.com
Mon Jul 28 13:24:00 BST 2008
On Sunday 27 July 2008, Vlad wrote:
> --- On Sun, 7/27/08, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
> > > > No. A read can result in any number data() emits.
> > For files
> > > > it will usually be
> > > > only one, but for streams it can be multiple.
> > >
> > > Does FileJob::write() work the same way? In other
> > words, do we have to
> > > check whether bytes_written == the number of bytes
> > sent, and if not, then
> > > attempt again to write what is left over?
> > No you don't have to try again. It does the retries
> > internally
> This difference between FileJob::read() and FileJob::write() gets
> confusing. I suggest _not_ explicitly giving assurance that everything will
> be written at once, even though most KIO slaves will retry internally. It
> won't hurt client apps to check whether everything was indeed written and
> to prepare to write the leftover again if needed.
Well, okay technically speaking there is no reassurance, but if write or read
fails to complete it is highly unlikely that retrying will help. So the
client should just accept it and report the error.
> This way, the behaviors of FileJob::read() and FileJob::write() remain
> consistent with each other and with POSIX read() and write(), which don't
> guarantee atomicity either (see write_all() in
There is something wrong with the way write_all is used. FileJob::write should
catch the return value and emit it as written(), and if the size is smaller
than data.size() follow up with the error that prevented completion.
More information about the kde-core-devel