Best practice for monitoring and reporting the writability of a QIODevice?



  • Do we have a best practice for monitoring and reporting the writability of a QIODevice?

    I've written a QIODevice that encapsulates the datagram type (SOCK_DGRAM) of UNIX domain socket (AF_UNIX). It emits the readyWrite() signal whenever the socket is writable. A QSocketNotifier tells my QIODevice when the socket is writable. This happens often, so the QIODevice emits readyWrite() often. My application spends a lot of time responding to the signal by doing nothing because it has nothing to write. I'd like to find a less CPU-intensive way.

    Other QIODevices don't inform when they are writable. The "UNIX implementation of QLocalSocket":http://qt.gitorious.org/qt/qtbase/blobs/7eca53b51a2c7cae0b39fedb0b78205504bfd64b/src/network/socket/qlocalsocket_unix.cpp definitely doesn't.



  • You should take a look at "QSocketNotifier":http://doc.qt.digia.com/qt/qsocketnotifier.html, pass it your socket file descriptor and use the enabled property. Whenever you receive the signal, you can disable the notifier so that you won't be notified again until you actually write something to it an re-enable it.



  • Thanks rcari. I am using QSocketNotifier. The slot I connected to its activate() signal disables the QSocketNotifier, emits the readyWrite() signal, then re-enables the QSocketNotifier. I could do as you suggest: not enable the QSocketNotifier. I suppose the same would apply to reading: just disable the QSocketNotifier and emit readyRead().



  • Yes that's it, and only re-enable it once an actual read or an actual write occurs.
    You can easily do in the proper read/write methods.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.