Сбой закрытия и немедленного повторного открытия COM-порта: почему? - PullRequest
1 голос
/ 20 августа 2009

Я пытаюсь выполнить «предполетные проверки», проверяя «открываемость» COM-порта перед тем, как запустить диалоговое окно, которое позволяет пользователю выполнять компортные операции.

Вот кодовая последовательность в общих чертах:

handle = CreateFile("\\\\.\\COM4:", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED,NULL);

if (handle != INVALID_HANDLE_VALUE)
{
  CloseHandle(handle);
  DoTheWork("\\\\.\\COM4:");
}
else
{ 
  ShowMessage("I'm sorry Dave, I can't do that"); 
} 

...

void DoTheWork(char * port)
{
  handle = CreateFile(port, GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED,NULL);
  /// do lots of stuff
  CloseHandle(port);
}

Вот проблема: «DoTheWork» - это проверенная и проверенная функция, которая сама по себе работает правильно. Сбой происходит только при вызове сразу после более ранних вызовов CreateFile / CloseHandle, когда второй CreateFile возвращает E_ACCESSDENIED.

Хуже того, если я медленно перебираю код в отладчике, он работает просто отлично.

Кажется, мне нужно Sleep () после первого closeHandle, но это похоже на хак - и я не могу понять, как долго это должно быть.

Ответы [ 3 ]

2 голосов
/ 20 августа 2009

Системе требуется немного времени, чтобы закрыть ресурс. Возможно, есть какой-то загадочный способ проверить, освобожден ли он, но я не знаю, что это такое. Что я знаю, так это то, что если вы проверите ключ реестра:

HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM

Вы увидите, какие последовательные порты доступны, не открывая их, что должно решить вашу проблему.

1 голос
/ 20 августа 2009

Попробуйте вызвать PurgeComm () или FlushFileBuffers () на дескрипторе перед его закрытием.

0 голосов
/ 20 августа 2009

Что ж, после еще большего траления я нашел это , которое относится к Windows CE, а не к Win32.

После двухсекундной задержки CloseHandle вызывается перед портом закрыт и ресурс освобожден.

Полагаю, то же самое относится и к Win32, но я не нашел ни одного документально подтвержденного доказательства.

...