Estoy instalando mingw-w64 en Windows y hay dos opciones: hilos win32 y hilos posix. Sé cuál es la diferencia entre win32 threads y pthreads, pero no entiendo cuál es la diferencia entre estas dos opciones. Dudo que si elijo subprocesos posix, me impedirá llamar a funciones de WinAPI como CreateThread.
Parece que esta opción especifica qué API de subprocesos utilizará algún programa o biblioteca, pero ¿por qué? ¿Por GCC, libstdc ++ o por algo más?
Encontré esto: ¿ Cuál es la diferencia entre thread_posixs y thread_win32 en el puerto gcc de Windows?
En resumen, para esta versión de mingw, la versión threads-posix usará la API posix y permitirá el uso de std :: thread, y threads-win32 usará la API win32 y deshabilitará la parte std :: thread del estándar.
Ok, si selecciono subprocesos win32, std :: thread no estará disponible, pero los subprocesos win32 se seguirán usando. ¿Pero usado por qué?
Respuestas:
GCC viene con una biblioteca en tiempo de ejecución del compilador (libgcc) que utiliza para (entre otras cosas) proporcionar una abstracción del sistema operativo de bajo nivel para la funcionalidad relacionada con múltiples subprocesos en los idiomas que admite. El ejemplo más relevante es libstdc ++ 's C ++ 11
<thread>,<mutex>y<future>que no tienen una aplicación completa cuando se construye GCC con su modelo enhebrar Win32 interna. MinGW-w64 proporciona un winpthreads (una implementación de pthreads en la parte superior de la API de múltiples subprocesos de Win32) que GCC puede luego vincular para habilitar todas las funciones sofisticadas.Debo enfatizar que esta opción no le prohíbe escribir el código que desee ( NO tiene absolutamente ninguna influencia en la API que puede llamar en su código). Solo refleja lo que las bibliotecas en tiempo de ejecución de GCC (libgcc / libstdc ++ / ...) usan para su funcionalidad. La advertencia citada por @James no tiene nada que ver con el modelo de subprocesamiento interno de GCC, sino más bien con la implementación CRT de Microsoft.
Para resumir:
posix: habilita las funciones de subprocesos múltiples de C ++ 11 / C11. Hace que libgcc dependa de libwinpthreads, de modo que incluso si no llama directamente a la API de pthreads, estará distribuyendo la DLL de winpthreads. No hay nada de malo en distribuir una DLL más con su aplicación.win32: Sin funciones de subprocesos múltiples de C ++ 11.Ninguno de los dos influye en ningún código de usuario que llame a las API de Win32 o API de pthreads. Siempre puedes usar ambos.
fuente
g++-mingw-w64-x86-64proporciona dos archivosx86_64-w64-mingw32-g++-win32yx86_64-w64-mingw32-g++-posix, yx86_64-w64-mingw32-g++tiene un alias para uno de ellos; verupdate-alternatives --display x86_64-w64-mingw32-g++.--threads=win32. Por lo tanto, siempre que los bits faltantes no se implementen en GCC, debe configurar GCC con--threads=win32.Partes del tiempo de ejecución de GCC (el manejo de excepciones, en particular) dependen del modelo de subprocesamiento que se utilice. Por lo tanto, si está utilizando la versión del tiempo de ejecución que se creó con subprocesos POSIX, pero decide crear subprocesos en su propio código con las API de Win32, es probable que tenga problemas en algún momento.
Incluso si está utilizando la versión de subprocesamiento de Win32 del tiempo de ejecución, probablemente no debería llamar directamente a las API de Win32. Citando las preguntas frecuentes de MinGW :
fuente
Tenga en cuenta que ahora es posible utilizar algunos de los std :: thread de C ++ 11 en el modo de subprocesamiento win32. Estos adaptadores de solo encabezado funcionaron de fábrica para mí: https://github.com/meganz/mingw-std-threads
A partir del historial de revisiones, parece que hay algún intento reciente de hacer que esto sea parte del tiempo de ejecución de mingw64.
fuente