D29265: Implement buffering in the DataStream class, to improve performance on Windows.

[David Faure]

dfaure added inline comments.

INLINE COMMENTS

> dvratil wrote in datastream_p.cpp:45
> Why don't you just handle the exception in the destructor?

Hmm, and do what with it? The calling code knows what to do with the exception, here we don't.

In fact that's the same as just folding flush() into the destructor, and just not throwing an exception at all.

But the question remains, won't the caller need to know. Let's see....

> connection.h:164
>      stream << std::move(response);
> +    stream.flush();
>      if (!m_socket->waitForBytesWritten()) {

This code here throws ProtocolException (see also line 167), so that e.g. slotSendHello() disconnects the socket. Or in handleIncomingData, when sendResponse throws, we set m_connectionClosing to true in order to break from the loop and disconnect the socket.

If we eat the exception in ~DataStream none of that will happen. Isn't that a problem?

> notificationsubscriber.cpp:688
>      } catch (const ProtocolException &e) {
>          qCWarning(AKONADISERVER_LOG) << "ProtocolException while writing into stream for subscriber" << mSubscriber << ":" << e.what();
>      }

ok here it's just a warning, we can do that.

REPOSITORY
  R165 Akonadi

REVISION DETAIL
  https://phabricator.kde.org/D29265

To: dfaure, dvratil, kfunk
Cc: kde-pim, fbampaloukas, dcaliste, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20200430/112ce28a/attachment-0001.html>