int32_t rup2 = roundUpPower2(nPoints);
if (rup2 == nPoints || rup2 == nPoints + 1)
{
return nPoints;
}
int32_t leaveLevelCapacity = rup2 / 2;
int32_t allAbove = leaveLevelCapacity - 1;
int32_t pointsOnLeave = nPoints - allAbove;
int32_t iteration = roundDownLog2(pointsOnLeave);
int32_t leaveSize = 1;
int32_t gap = leaveLevelCapacity;
for (int32_t i = 1; i <= iteration; ++i)
{
leaveSize += gap / 2;
gap /= 2;
}
return (allAbove + leaveSize);
Переключитесь на асинхронную версию: BeginWaitForConnection
.
, Если это действительно когда-либо завершается, Вам будет нужен флаг, таким образом, обработчик завершений сможет просто звонить EndWaitForConnection
поглощение любых исключений, и выход (назовите Конец..., чтобы гарантировать, что любые ресурсы в состоянии быть очищенными).
Один из способов, который может работать, - это проверка m_bShutdownRequested сразу после WaitForConnection.
В процессе выключения установите значение bool. После этого отправьте фиктивные сообщения всем существующим каналам, чтобы они открыли соединение, проверили bool и завершили работу.
Это глупо, но это единственный метод, который у меня сработал. Создайте «поддельный» клиент и подключитесь к именованному каналу, чтобы пройти через WaitForConnection. Работает каждый раз.
Кроме того, даже Thread.Abort () не помог мне решить эту проблему.
_pipeserver.Dispose();
_pipeserver = null;
using (NamedPipeClientStream npcs = new NamedPipeClientStream("pipename"))
{
npcs.Connect(100);
}