我想要一个QUdpSocket，但是在这样的不同线程中读取/写入数据：
void UDPLink::writeBytes(const char* data, qint64 size)
{
// Broadcast to all connected systems
for (int h = 0; h < hosts.size(); h++)
{
QHostAddress currentHost = hosts.at(h);
quint16 currentPort = ports.at(h);
socket->writeDatagram(data, size, currentHost, currentPort);
}
}
void UDPLink::readBytes()
{
while (socket->hasPendingDatagrams())
{
QByteArray datagram;
datagram.resize(socket->pendingDatagramSize());
QHostAddress sender;
quint16 senderPort;
socket->readDatagram(datagram.data(), datagram.size(), &sender, &senderPort);
// FIXME TODO Check if this method is better than retrieving the data by individual processes
emit bytesReceived(this, datagram);
}
}
该readBytes()触发插座的readyRead信号。但是writeBytes在工作线程中，而readBytes在主线程中。这个可以吗？
但是writeBytes在工作线程中，而readBytes在主线程中。这个可以吗？
如果您使用的是原始POSIX套接字（例如，一个int文件描述符和BSD套接字API的sendto（）调用），那就可以了。但是，QudpSocket是从QObject派生的，并且QObjects不能同时由多个线程访问。特别是，快速看一下QUdpSocket :: writeDatagram（）方法的实现，就会发现该方法可以完成诸如底层套接字的延迟初始化，文件描述符的缓存以及信号的发出之类的操作，而这些操作中的任何一个都可能与同时进行的交互作用很差。给定正确的（错误的？）时间，从另一个线程进行的非同步访问。您的代码可能无法做到这一点，但是我不相信它可以一直或在所有系统上可靠地工作。
我的建议是创建两个QUdpSocket对象，一个用于发送，一个用于接收。这将确保避免争用条件，并且额外的QUdpSocket对象并不是让您高枕无忧的巨大代价。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句