socket :: readyRead()에 대한 새로운 신호가 실행되는 이유는 이전 슬롯이 아직 처리 중인데도 마찬가지입니다.

Question

다음 포스트에 따르면 현재 실행중인 슬롯이 완료되면 방출 된 신호가 제공됩니다.
Wait for a SLOT to finish the execution with Qt

단일 스레드 인 ssl 소켓을 기반으로하는 클라이언트 - 서버 통신 응용 프로그램이 있습니다.

connect(socket, &QSslSocket::readyRead, [&]() { myObject.Read(); }); 

클라이언트 & 서버가 서로에게 약간의 사용자 정의 메시지를 보낼 수 있습니다. 메시지가 보내거나받을 때마다 ACK 바이트 (00)를 보냅니다.
대부분의 경우, 나는 Read()이 실행 중간에있을 때 다음 readyRead()이 제공됩니다. 시작 부분에 & 끝의 디버그 문을 넣으십시오. myObject->Read(). 그들은 디버그 시작이 다시 &으로 다시 호출됨을 확인합니다. 중단 점에서도 마찬가지입니다.

너무 많은 양의 데이터가 수신되면 재귀 적 스택 프레임이 너무 많아 Read() 초입니다. 앱 GUI가 느려지거나 충돌이 발생합니다.
일반적으로이 재귀는 클라이언트가 myObject->Read()의 일부로 ACK를 보내려고 할 때 발생합니다. 그 시간에 readyRead()이 부수적으로 신호를 받으면 &도 수신됩니다. 그러나 이전 신호의 슬롯은 여전히 ​​처리 중입니다.

질문 :

• 는 Qt는 프레임 워크 슬롯은 여전히 ​​중도 (단일 스레드) 때 사이에 신호를 수용 할 수 있습니까?
• 이 소켓 특정 시나리오를 수정하는 방법은 무엇입니까?

주 :
- 단일 스레드 기본적으로는의 Qt::ConnectionType이 DirectConnection입니다. 나는 QueuedConnection으로 시도했지만 그 결과는 같습니다.
- myObject.Read()은 매우 복잡하며 다른 많은 함수 호출이 있습니다. 이것이 문제의 원인이된다면 무엇을 찾아야할지 알려주세요. 실제 코드를 작성하는 것은 비현실적입니다.

Answer 1

이벤트 루프가 해제되어 재귀 호출 readyRead()이 발생했습니다. 다음 기능은 이벤트 루프가 해제되는 원인이되었다 : 그것은 그 의미 것 같은 QCoreApplication::processEvents()

SslSocket::flush()

1. 제 1 회는, 이해할 수있다. 그러나 제 2의 flush()는 놀람이었다. 그것의 documentation은 그렇게 진술하지 않습니다. 적어도 제 디버깅에서는 flush()이 호출 될 때마다 readyRead()이 호출되고 요청 된 것을 보여주었습니다. 그것도 Qn에서 보아라.

   processEvent()은 데이터로드가 높을 때 GUI의 응답 성을 높이기위한 것입니다. 그러나 우리는 같은 것을 위해 또 다른 선택을해야 할 필요가 있다고 생각합니다.