CloseHandle() regresa antes de que el puerto serie esté realmente cerrado

Question

Estoy tirando de mi cabello tratando de averiguar cuándo un puerto serie termina de cerrarse para que pueda volver a abrirlo. Resulta que CloseHandle() regresa antes de que el puerto esté realmente desbloqueado.

Estoy abriendo un puerto serie utilizando CreateFile(FILE_FLAG_OVERLAPPED), asociándolo con un CompletionPort usando CreateIoCompletionPort(), leer/escribir en él usando ReadFile(), WriteFile() y cerrándola usando CloseHandle().

Me he dado cuenta de que si cierro y vuelvo a abrir un puerto serie con la suficiente rapidez, obtengo un ERROR_ACCESS_DENIED de vuelta desde CreateFile(). Esto está sucediendo a pesar del hecho de que estoy esperando que regrese el CloseHandle(), luego esperando que todas las operaciones pendientes de lectura/escritura asociadas con ese identificador vuelvan del puerto de finalización. Seguramente hay una mejor manera :)

¿Cómo cierro un puerto serie sincrónicamente? Por favor, no vuelva a intentar loops, sleep() o algunos otros hacks baratos.

EDIT: Quizás esto tiene algo que ver con mi uso de los puertos de terminación y FILE_FLAG_OVERLAPPED. Recibo una devolución de llamada cuando se completan las operaciones de lectura/escritura. ¿Hay algún tipo de devolución de llamada para el cierre del puerto?

Answer 1

Creo que el problema es con el controlador que sirve el puerto COM. Por lo tanto, no habrá API para "cerrar realmente" el puerto COM.

BTW, después de cerrar el identificador del archivo, no hay necesidad de esperar a que todas las E/S sobresalientes se completen con errores. En el momento en que CloseHandle devuelve todas las E/S pendientes son ya completadas/canceladas, usted acaba de recibir las devoluciones de llamada de forma asincrónica (ya sea a través del puerto de terminación o la cola APC, no importa).

Específicamente, los controladores FTDI (aquellos que emulan COM-> USB) son muy difíciles.

Es posible que solo recomiende intentar vaciar los datos antes de cerrar la manija. Puede esperar a que todas las E/S completen antes de cerrando el puerto COM (si esto es aplicable para su caso). Alternativamente, puede llamar al SetCommMask y WaitCommEvent para asegurarse de que no haya datos de envío pendientes. Espero que esto pueda ayudar.

EDIT:

¿Se CloseHandle inmediatamente (antes de que vuelva) cancelar toda la espera de E/S en el archivo de manejar?

Estrictamente hablando - no.

Puede haber otras referencias para el objeto de archivo. Por ejemplo, un código de modo de usuario puede llamar al DuplicateHandle, o un controlador en modo kernel puede llamar al ObReferenceObjectByXXXX. En tal caso, el objeto al que se refiere el identificador no se libera necesariamente.

Cuando se cierra el último identificador se llama al controlador DispatchCleanup. Debe cancelar todas las E/S pendientes según this.

Sin embargo, mientras que un hilo está dentro de un CloseHandle - en teoría, puede emitir otro I/O de otro hilo (si tiene suerte, el identificador seguirá siendo válido). Mientras está en la llamada a una función de E/S (como WriteFile o etc.), el sistema operativo aumenta temporalmente el contador de referencia al objeto. Esto a su vez puede iniciar otra E/S, que no se cancelará directamente mediante la invocación CloseHandle.

Sin embargo, en este caso el O/S cerrará el asa inmediatamente después de que se emite la nueva E/S, porque el recuento de referencias al objeto alcanzó 0 nuevamente.

Para que en un escenario tan pervertido pueda ocurrir una situación en la que inmediatamente después de una llamada al CloseHandle no pueda volver a abrir el archivo.

Answer 2

Asegúrese de que su lector y su escritor fallan (con un identificador no válido) después de haber emitido la solicitud CloseHandle() en otro hilo, antes de intentar tocar el dispositivo nuevamente. Puede usar esto como una señal para limpiar todo su manejo antes de intentar emitir otro CreateFile. Debo decir que los puertos de terminación parecen innecesariamente barrocos.

Answer 3

Cuando abre un puerto COM en una secuencia, el sistema operativo abre otra cadena oculta para hacer la E/S. Estoy tratando de resolver el cierre de un puerto también. Cerca de lo que puedo decir, un método que puede funcionar es: 1) Suspender el hilo que abrió el puerto COM, 2) PurgarComm() para detener todas las E/S y vaciar todos los buffers de E/S de lectura/escritura, y 3) luego intentar para cerrar el puerto COM. Puede haber una espera para un solo objeto involucrado para determinar cuándo se suspende el hilo con el puerto COM. A menos que el puerto COM sea absolutamente necesario cerrar, estoy considerando dejar abierto el puerto COM y dejar que el WinProc procese el comando IDM_Exit para cerrar el puerto COM, los hilos y la aplicación. No es lo que quería, sino una opción con la que podría vivir. Estoy usando una conexión USB a puerto serie y no estoy seguro de qué problemas me está causando. Sé que si está utilizando una interfaz USB a puerto serie, necesita configurar el pin 20 alto (DTR). El pin 20 ayuda a alimentar la interfaz, pero solo proporciona alrededor de 30 ma más o menos. Si todo esto funciona, haré una actualización de esta publicación y le diré cómo puedo cerrar el puerto COM. ¡Windows ha hecho un lío con el controlador del puerto serial y parece estar contento de dejar las cosas en desorden!