Mir

Comment 3 for bug 1395421

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Protocol (exchange_buffer) replies are being sent from the compositor thread, holding up the render loop

I think the core of the issue is this synchronous socket write. Not only does the render loop get held up for one write() per client, but the OS is likely to context switch in that time too. Last time I measured this, it took around 1ms per client, which is a bit scary if you want to run multiple clients and still have time to composite them all within 16ms...

void mfd::SocketMessenger::send(char const* data, size_t length, FdSets const& fd_set)
{
    static size_t const header_size{2};
    mir::VariableLengthArray<mf::serialization_buffer_size> whole_message{header_size + length};

    whole_message.data()[0] = static_cast<unsigned char>((length >> 8) & 0xff);
    whole_message.data()[1] = static_cast<unsigned char>((length >> 0) & 0xff);
    std::copy(data, data + length, whole_message.data() + header_size);

    std::unique_lock<std::mutex> lg(message_lock);

    // TODO: This should be asynchronous, but we are not making sure
    // that a potential call to send_fds is executed _after_ this
    // function has completed (if it would be executed asynchronously.
    // NOTE: we rely on this synchronous behavior as per the comment in
    // mf::SessionMediator::create_surface
    ba::write(*socket, ba::buffer(whole_message.data(), whole_message.size()));

    for (auto const& fds : fd_set)
        mir::send_fds(socket_fd, fds);
}