Bifurcación combinada pthread-win32
de RedFox20 + Oktonion + WinBuild
Cambios en PThread https://github.com/WinBuilds/pthread-win32:
Esta es una bifurcación de la versión 2.10.0.0 del paquete pthreads-win32. El ABI de esta horquilla es diferente al original.
Cambios realizados:
El tipo de contador de reutilización en ptw32_handle_t
se ha cambiado de int
a size_t
para facilitar servidores de larga ejecución.
Se eliminaron elementos no utilizados de pthread_once_t
Esta biblioteca se prueba frecuentemente con nuestros otros proyectos de Visual Studio 2022.
Generalmente uso (y he usado) los archivos de proyecto MSVC20xx para mi trabajo. Los Makefiles se han utilizado con mucha menos frecuencia y es posible que estén desactualizados.
Tenga en cuenta el mensaje de confirmación d4b0ef6b: si bien el proyecto MSVC2022/2019 se configuró para adaptarse a mi configuración interna, es posible que no se adapte a la suya.
Por supuesto, siempre puede editar la configuración a mano, pero cuando necesita hacer esto para muchos archivos de proyecto vcxproj
, programar la tarea puede ser el camino a seguir. Consulte update-vcxproj.js
y patch-vcxproj.js
para ver scripts de muestra que hacen este tipo de cosas. Los uso para asegurarme de que todos mis proyectos C/C++ tengan exactamente la misma configuración de compilación para no tener sorpresas desagradables en tiempo de ejecución porque algún proyecto decidió compilar con bibliotecas de tiempo de ejecución de depuración/liberación estática/DLL ligeramente diferentes. etc.etc.: ¿las tropecientas formas en que puedes conseguirlo? por su sistema de compilación en un entorno Windows. ¡Divertido! ?
(2021-12-17)
Esta es una micro versión con correcciones en su mayoría administrativas.
mkdir b && cd b && cmake -G "Visual Studio 16 2019" ..
: OK. Esto significa que se han solucionado varios errores ocultos y hemos incluido una solución para la basura de CMake (todavía no me gusta esa herramienta) cuando las fuentes de C deben compilarse condicionalmente como C++ (consulte también pthread-EH.cpp y pthread-JMP.c: dos nuevos archivos fuente contenedores). Esta es una micro versión con correcciones en su mayoría administrativas.
Las compilaciones de MSVC y MinGW64 se probaron en la arquitectura SMP (Intel x64 Hex Core) completando el conjunto de pruebas incluido, así como las pruebas de estrés y de banco.
Asegúrese de ejecutar sus compilaciones con el conjunto de pruebas. Si ve fallas, considere cómo sus cadenas de herramientas podrían estar contribuyendo a la falla. Consulte el archivo README para obtener descripciones más detalladas de las cadenas de herramientas y sistemas de prueba que hemos utilizado para que las pruebas pasen con éxito.
Recomendamos MinGW64 sobre MinGW para compilaciones GNU CC de 64 y 32 bits solo porque el manejo de excepciones MinGW DWARF2 con compilaciones C++ causa algunos problemas con la cancelación de subprocesos.
MinGW64 también incluye su propia implementación nativa de pthreads, que quizás prefieras usar. Si desea crear nuestra biblioteca, deberá seleccionar la opción de subprocesos nativos de Win32 en el momento de la instalación. Recomendamos también seleccionar el método de manejo de excepciones SJLJ para compilaciones MinGW64-w32. Para compilaciones MinGW64-w64, el método de manejo de excepciones SJLJ o SEH debería funcionar.
(2018-08-08)
Tenga en cuenta que esta es una nueva versión importante. El incremento de la versión principal introduce dos cambios de ABI junto con otros cambios de nombres que requerirán la recompilación de las aplicaciones de enlace y posiblemente algunos cambios textuales en las referencias de macros en tiempo de compilación en los archivos de configuración y fuente, por ejemplo, cambios de PTW32_* a PTW32_ , ptw32_ a ptw32_*, etc. .
Con el acuerdo de todos los contribuyentes importantes y relevantes, pthreads-win32 / pthreads4w versión 3, con la excepción de cuatro archivos, se publica bajo los términos de la licencia Apache v2.0. El APLv2 es compatible con las licencias GPLv3 y LGPLv3 y por tanto este código podrá seguir incluido legalmente dentro de los proyectos GPLv3 y LGPLv3.
Un colaborador sustancial y relevante se definió como aquel que ha contribuido con código original que implementa una capacidad presente en las versiones futuras. Esto excluye a varios contribuyentes que han contribuido con código que ha quedado obsoleto, o que han proporcionado parches para corregir errores, reorganizar el código con fines estéticos o prácticos, o mejorar los procesos de compilación. Esta distinción era necesaria para avanzar en la probabilidad de que no todos los contribuyentes fueran contactables. Todos los contribuyentes están listados en el archivo COLABORADORES.
Los cuatro archivos que seguirán siendo LGPL pero cambiarán a v3 son archivos utilizados para configurar las compilaciones del entorno GNU:
aclocal.m4
configure.ac
GNUmakefile.in
tests/GNUmakefile.in
Los colaboradores que solicitaron este cambio o lo aceptaron cuando fueron consultados son:
Las versiones de pthreads-win32/pthreads4w versión 2 seguirán siendo LGPL, pero la versión 2.11 y posteriores se publicarán bajo la versión 3 de esa licencia, de modo que cualquier adición al código de la versión 3 de pthreads4w que esté respaldado a la versión 2 no contaminará ese código.
Es posible que algunos cambios realizados desde el 26 de febrero de 2011 en adelante no sean compatibles con sistemas anteriores a Windows 2000.
Las nuevas correcciones de errores en todas las versiones desde 2.8.0 NO se han aplicado a la serie 1.xx.
Las compilaciones MSVC, MinGW y MinGW64 se probaron en la arquitectura SMP (Intel x64 Hex Core) completando el conjunto de pruebas incluido, así como las pruebas de estrés y de banco.
Asegúrese de ejecutar sus compilaciones con el conjunto de pruebas. Si ve fallas, considere cómo sus cadenas de herramientas podrían estar contribuyendo a la falla. Consulte el archivo README para obtener descripciones más detalladas de las cadenas de herramientas y sistemas de prueba que hemos utilizado para que las pruebas pasen con éxito.
Recomendamos MinGW64 sobre MinGW para compilaciones GNU CC de 64 y 32 bits solo porque el manejo de excepciones MinGW DWARF2 con compilaciones C++ causa algunos problemas con la cancelación de subprocesos.
MinGW64 también incluye su propia implementación nativa de pthreads, que quizás prefieras usar. Si desea crear nuestra biblioteca, deberá seleccionar la opción de subprocesos nativos de Win32 en el momento de la instalación. Recomendamos también seleccionar el método de manejo de excepciones SJLJ para compilaciones MinGW64-w32. Para compilaciones MinGW64-w64, el método de manejo de excepciones SJLJ o SEH debería funcionar.
Aparte de lo siguiente, esta versión tiene características equivalentes a la v2.11.0.
Esta versión introduce un cambio en pthread_t y pthread_once_t que afectará a las aplicaciones que se vinculan con la biblioteca.
pthread_t: sigue siendo una estructura pero extiende el contador de reutilización de 32 bits a 64 bits. En máquinas de 64 bits, el tamaño total del objeto no aumentará, simplemente le damos un buen uso a 4 bytes de relleno, reduciendo el riesgo de que el contador pueda variar en aplicaciones de ejecución muy larga desde pequeño hasta, efectivamente, cero. El contador de reutilización de 64 bits extiende el tiempo de ejecución sin riesgos de meses (suponiendo una vida útil promedio de subprocesos de 1 ms) a siglos (suponiendo una vida útil promedio de subprocesos de 1 ns).
pthread_once_t: elimina dos elementos obsoletos hace mucho tiempo y reduce su tamaño.
(2018-08-08)
Las nuevas correcciones de errores en todas las versiones desde 2.8.0 NO se han aplicado a la serie 1.xx.
Es posible que algunos cambios realizados desde el 26 de febrero de 2011 en adelante no sean compatibles con sistemas anteriores a Windows 2000.
pthreads-win32 / pthreads4w versión 2.11 y todas las versiones 2.x futuras se lanzarán bajo la Licencia pública menor de GNU versión 3 (LGPLv3).
La próxima versión principal de este software (versión 3) se lanzará bajo la licencia Apache versión 2.0 (ALv2). La versión 2.11 bajo LGPLv3 permitirá que las modificaciones a la versión 3 de este software se respalden a la versión 2 en el futuro. Además de esto, cualquier proyecto GPL que utilice actualmente esta biblioteca podrá seguir utilizando la versión 2 o 3 de este código en sus proyectos.
Para obtener más información, consulte: https://www.apache.org/licenses/GPL-compatibility.html
Para mantener la coherencia con este cambio, a partir de este momento las modificaciones a esta biblioteca solo se aceptarán en la versión 3 de este software según los términos de ALv2. Luego, cuando corresponda, se respaldarán a la versión 2.
Esperamos lanzar la versión 3 al mismo tiempo que lanzamos la versión 2.11.
Esta versión ha sido probada en arquitectura SMP (Intel x64 Hex Core) completando el conjunto de pruebas incluido, así como las pruebas de estrés y de banco.
Asegúrese de ejecutar sus compilaciones con el conjunto de pruebas. Si ve fallas, considere cómo sus cadenas de herramientas podrían estar contribuyendo a la falla. Consulte el archivo README para obtener descripciones más detalladas de las cadenas de herramientas y sistemas de prueba que hemos utilizado para que las pruebas pasen con éxito. Recomendamos MinGW64 sobre MinGW32 para compilaciones GNU CC de 64 y 32 bits. MinGW64 también incluye su propia implementación independiente de pthreads, que quizás prefieras usar.
Para compilaciones de cadenas de herramientas de Microsoft: (1) La vinculación estática requiere que tanto esta biblioteca como cualquier biblioteca o aplicación de vinculación se compilen con /MT de manera consistente.
(2) Las bibliotecas estáticas han sido renombradas como libpthreadV*.lib para diferenciarlas de las bibliotecas de importación de DLL pthreadV*.lib.
(3) Si está utilizando un enlace mixto, por ejemplo, vinculando la versión estática /MT de la biblioteca a una aplicación vinculada con /MD, es posible que pueda usar GetLastError() para interrogar el código de error porque la biblioteca establece ambos errno (a través de _set_errno ()) y SetLastError().
Elimine el intento de configurar PTW32_USES_SEPARATE_CRT en los encabezados, lo que puede provocar resultados inesperados. En determinadas situaciones, es posible que un usuario desee definirlo explícitamente en su entorno para invocar sus efectos, ya sea al compilar la biblioteca, una aplicación o ambas. Consulte LÉAME.NO PORTABLE. --Ross Johnson
La biblioteca debería ser más confiable en escenarios totalmente vinculados estáticamente. Nota: eliminamos el código PIMAGE_TLS_CALLBACK y volvimos al método anterior que parece ser más confiable en todas las ediciones del compilador.
Varias correcciones a GNUmakefile. Aunque este archivo se eliminó, para que esté completo, los cambios se registraron como confirmaciones en el repositorio.
MinGW64-w64 define pid_t como __int64. sched.h ahora refleja eso.
Se han solucionado varias pruebas que fallaban en máquinas bajo carga. A otras pruebas que utilizaron mecanismos toscos similares para sincronizar subprocesos (estas son pruebas unitarias) se les aplicaron las mismas mejoras: semaphore5.c reconoce que sem_destroy puede devolver EBUSY legítimamente; mutex6*.c, mutex7*.c y mutex8*.c reemplazaron un único Sleep() con un bucle de sondeo.
(2016-09-18)
Las nuevas correcciones de errores en todas las versiones desde 2.8.0 NO se han aplicado a la serie 1.xx.
Es posible que algunos cambios realizados desde el 26 de febrero de 2011 en adelante no sean compatibles con sistemas anteriores a Windows 2000.
Esta versión ha sido probada en arquitectura SMP (Intel x64 Hex Core) completando el conjunto de pruebas incluido, así como las pruebas de estrés y de banco.
Asegúrese de ejecutar sus compilaciones con el conjunto de pruebas. Si ve fallas, considere cómo sus cadenas de herramientas podrían estar contribuyendo a la falla. Consulte el archivo README para obtener descripciones más detalladas de las cadenas de herramientas y sistemas de prueba que hemos utilizado para que las pruebas pasen con éxito. Recomendamos MinGW64 sobre MinGW32 para compilaciones GNU CC de 64 y 32 bits. MinGW64 también incluye su propia implementación independiente de pthreads, que quizás prefieras usar.
Nuevas rutinas: pthread_timedjoin_np() pthread_tryjoin_np()
sched_getaffinity() sched_setaffinity() pthread_getaffinity_np() pthread_setaffinity_np() pthread_attr_getaffinity_np() pthread_attr_setaffinity_np()
pthread_getname_np() pthread_setname_np() pthread_attr_getname_np() pthread_attr_setname_np()
pthread_win32_getabstime_np()
Los entornos de compilación GNU (MinGW32 y MinGW64) ahora tienen la opción de usar autoconf para configurar automáticamente la compilación.
Compilaciones: se agregaron nuevos objetivos de archivos MAKE y se modificaron o eliminaron los objetivos existentes. Por ejemplo, el objetivo es crear y probar todas las configuraciones posibles de bibliotecas estáticas y dll.
Las compilaciones del compilador GNU ahora utilizan explícitamente la compatibilidad con los estándares ISO C y C++ 2011. Si su compilador GNU no admite esto, considere actualizarlo. La configuración automática ahora es posible mediante el script 'configurar'. El script debe generarse mediante autoconf; consulte el archivo README. Gracias a Keith Marshall del proyecto MinGW.
Enlace estático: la funcionalidad autostática se ha movido a dll.c y se ha ampliado para que las compilaciones que utilizan MSVC8 y versiones posteriores ya no requieran que las aplicaciones llamen a pthread_win32_thread_detach_np(). Es decir, toda la funcionalidad de DllMain ahora es automática para la vinculación estática de estas compilaciones.
Se han deshabilitado algunos destinos de enlace estático de nmake: debido a un problema con el comportamiento de TLS, se han deshabilitado los destinos de nmake V*-small-static* en Makefile. El problema se expone en tests/semaphore3.c donde la llamada pthread_self() dentro del hilo no devuelve el identificador de hilo POSIX correcto, pero en su lugar devuelve un nuevo identificador de hilo POSIX "implícito". Los identificadores de pthread implícitos tienen un estado de subproceso desconectado, lo que hace que la llamada pthread_detach() dentro del subproceso devuelva EINVAL. Los objetivos V*-static* parecen no verse afectados. La principal diferencia es que estos últimos se generan a partir de una única unidad de compilación.
El enlace estático de archivos de objetos pequeños ahora funciona (MinGW). Se requiere el código autostático, pero nada hacía referencia explícita a este código, por lo que se estaba optimizando.
sem_getvalue() podría devolver el valor de errno en lugar de configurar errno y devolver -1.
Los valores de Errno se perdían si la biblioteca estaba vinculada estáticamente con la biblioteca de tiempo de ejecución, lo que significa también que la aplicación usaba una instancia de tiempo de ejecución separada. Este sigue siendo el caso, excepto que se ha agregado un modificador de compilación que permite incorporar un estado de error más sólido, es decir, permitir que el código de retorno se recupere mediante GetLastError().
Se identificó la causa de fallas significativas relacionadas con la cancelación y pthread_exit() para la configuración de compilación de GCE (GNU C++) como procedente de Mingw32. No estoy seguro si esto es general o solo cuando se crean bibliotecas y aplicaciones de 32 bits que se ejecutan en sistemas de 64 bits. Estos fallos no surgen con las compilaciones Mingw64 de 32 bits (GCC creada con multilib habilitado) que se ejecutan en sistemas de 64 bits.
El error pthread_key_delete() introducido en la versión 2.9.x provocó que esta rutina fallara de una manera que el conjunto de pruebas no detectaba. Se agregó una nueva prueba para confirmar que esta rutina se comporta correctamente, particularmente cuando las claves con destructores se eliminan antes de que salgan los subprocesos.
pthread_win32_process_attach_np() soluciona posibles fallos/seguridad relacionados con la búsqueda y carga de QUSEREX.DLL.
_POSIX_THREAD_ATTR_STACKADDR ahora se establece en -1 en pthread.h. Como consecuencia, pthread_attr_setstackaddr() ahora devuelve ENOSYS. Anteriormente, el valor se almacenaba y se podía recuperar, pero no se utilizaba. pthread_attr_getstackaddr() devuelve ENOSYS correspondientemente.
Se corrigió una posible pérdida de memoria en pthread_mutex_init(). La fuga solo ocurriría si fallara la inicialización del mutex (extremadamente raro o nunca).
Se corrigieron tiempos de espera de menos de milisegundos, lo que provocaba que la biblioteca estuviera ocupada en espera.
Se soluciona una condición de carrera y falla en las cerraduras MCS. El código de administración de colas de camarero en ptw32_mcs_lock_acquire competía con el código de administración de colas en ptw32_mcs_lock_release y provocaba una falla de segmentación.
(27/05/2012)
Las nuevas correcciones de errores en esta versión desde 2.8.0 NO se han aplicado a la serie 1.xx.
Esta versión reemplaza una versión 2.9.0 extremadamente breve y agrega algunos cambios de última hora no relacionados con el código para incorporar mejores propiedades descriptivas en las DLL para indicar la arquitectura de destino y los entornos de compilación.
Es posible que algunos cambios posteriores al 26 de febrero de 2011 en CVS no sean compatibles con sistemas anteriores a Windows 2000.
Ahora se desaconseja el uso de otra versión de la biblioteca que no sea "C". Es decir, la versión "C++" no pasa algunas pruebas y no proporciona ninguna funcionalidad adicional.
Esta versión se ha probado en la arquitectura SMP (Intel x64 Hex Core) completando el conjunto de pruebas incluido, las pruebas de estrés y de banco.
Las propiedades de DLL ahora incluyen correctamente la arquitectura de destino, es decir, haga clic derecho en el archivo pthreadVC2.dll en el explorador y elija la pestaña Detalles para mostrar el compilador y la arquitectura en el campo de descripción, por ejemplo, "MS C x64" o "MS C x86".
La dependencia de la biblioteca winsock ahora es discrecional mediante #define RETAIN_WSALASTERROR
en config.h. No está definido de forma predeterminada a menos que se defina WINCE (porque yo (RJ) no estoy seguro de la dependencia allí).
(Compilaciones MSC y GNU) La biblioteca vinculada estáticamente ahora se inicializa y limpia automáticamente al iniciar/salir del programa, es decir, las aplicaciones vinculadas estáticamente no necesitan llamar explícitamente a las rutinas pthread_win32_process_attach_np() y pthread_win32_process_detach_np(). La rutina por subproceso pthread_win32_thread_detach_np() también se llama al salir del programa para limpiar los recursos POSIX adquiridos por el subproceso nativo principal de Windows, si yo (RJ) entiendo el proceso correctamente. Es posible que otros subprocesos nativos de Windows que llaman a rutinas API POSIX necesiten llamar a la rutina de separación de subprocesos al salir del subproceso si la aplicación depende de recursos POSIX recuperados o de la ejecución de destructores POSIX TSD (TLS). Consulte README.NONPORTABLE para obtener descripciones de estas rutinas.
Se implementan mutexes robustos dentro del alcance PROCESS_PRIVATE. TENGA EN CUENTA que las funciones pthread_mutex_* pueden devolver códigos de error diferentes para mutex robustos que en el uso normal; por ejemplo, se requiere pthread_mutex_unlock para verificar la propiedad de todos los tipos de mutex cuando el mutex es robusto, mientras que esto no ocurre para los tipos "normales" no tipo mutex robusto.
pthread_getunique_np se implementa para compatibilidad a nivel de fuente con algunas otras implementaciones. Esta rutina devuelve un número de secuencia de 64 bits que está asociado de forma única con un subproceso. Las aplicaciones pueden utilizarlo para ordenar o codificar identificadores de subprocesos POSIX.
Muchos más cambios para los sistemas de 64 bits.
Varias modificaciones y correcciones para compilar y probar WinCE.
Corrija pthread_cond_destroy(): no debería ser un punto de cancelación. Se solucionaron otros problemas menores de construcción.
Elimine la posible condición de interbloqueo de pthread_cond_destroy().
Varias modificaciones para compilar y probar para Win64.
Varias correcciones para la DLL auxiliar de cancelación asíncrona QueueUserAPCEx (esta es una descarga separada) y limpiezas de código pthreads.
Se eliminó la posible referencia de puntero NULL.
Se eliminó el requisito de que las aplicaciones restrinjan la cantidad de subprocesos que llaman a pthread_barrier_wait solo al recuento de barreras. También redujo la contienda entre barrier_wait y barrier_destroy. Este cambio habrá ralentizado ligeramente las barreras, pero reducirá a la mitad el número de semáforos consumidos por barrera a uno.
Se corrigió una fuga de identificador en sched_[gs]etscheduler.
Se eliminaron todas las macros de compatibilidad de la función reentrante POSIX de pthread.h. Algunas simplemente no eran semánticamente correctas.
Los subprocesos ya no intentan pasar excepciones no detectadas fuera del alcance del subproceso (solo compilaciones C++ y SEH). Las excepciones no detectadas ahora hacen que el hilo salga con el código de retorno PTHREAD_CANCELED.
Muchas correcciones de casting, particularmente para x64, correcciones entrelazadas y reelaboraciones para x64.
La dependencia de la biblioteca winsock ahora es discrecional mediante #define RETAIN_WSALASTERROR
en config.h. No está definido de forma predeterminada a menos que se defina WINCE (porque RJ no está seguro de la dependencia allí).
Varios mutex POSIX estáticos utilizados para la gestión interna fueron reemplazados por bloqueos basados en colas MCS para reducir el consumo de recursos, en particular el uso de objetos Win32.
Por seguridad, QuserEx.dll, si se utiliza, ahora debe instalarse en la carpeta Sistema de Windows.
robust[1-5].c - Mutexes robustos secuencia1.c - números de secuencia únicos por subproceso
Todas las pruebas mutex*.c, cuando correspondía, se han modificado para probar también mutex robustos en las mismas condiciones. Se agregaron pruebas de banco mutex sólidas a benchtest*.c cuando corresponda.
(22 de diciembre de 2006)
Las nuevas correcciones de errores en esta versión desde 2.7.0 no se han aplicado a la serie de versiones 1.xx. Probablemente sea hora de abandonar la versión 1.
Esta versión aún no se ha probado en arquitecturas SMP. Todas las pruebas se realizan en un sistema monoprocesador.
Sem_destroy podría devolver EBUSY aunque no hubiera subprocesos esperando en el semáforo. También se han eliminado otras carreras relacionadas con la invalidación de estructuras de semáforo (internamente).
semaphore5.c: prueba la corrección de errores mencionada anteriormente.
(2005-06-04)
Todas las características nuevas de esta versión se han adaptado a la versión 1.11.0, incluida la incorporación de bloqueos MCS en pthread_once; sin embargo, las versiones 1 y 2 siguen siendo incompatibles a pesar de que ahora son idénticas en rendimiento y funcionalidad.
Esta versión ha sido probada (pasó el conjunto de pruebas) en sistemas monoprocesador y multiprocesador.
Pthread_once se ha vuelto a implementar para eliminar el aumento de prioridad y otras complejidades para mejorar la solidez. Se han eliminado las carreras para identificadores de Win32 que no son exclusivos de reciclaje. La forma general de pthread_once es ahora la misma que sugirió anteriormente Alexander Terekhov, pero en lugar del 'mutex con nombre', se ha implementado un bloqueo basado en cola que tiene las propiedades requeridas de autoinicialización y destrucción dinámicas. Esta cerradura también es eficiente. La ABI no se ve afectada ya que el tamaño de pthread_once_t no ha cambiado y PTHREAD_ONCE_INIT no ha cambiado; sin embargo, las aplicaciones que miran dentro de pthread_once_t, que se supone que es opaco, se romperán.
(2005-05-19)
Todas las correcciones de errores y las nuevas funciones de esta versión se han adaptado a la versión 1.10.0.
Esta versión ha sido probada (pasó el conjunto de pruebas) en sistemas monoprocesador y multiprocesador. Gracias a Tim Theisen de TomoTherapy por ejecutar exhaustivamente las pruebas MP y por proporcionar observaciones y datos cruciales cuando se detectan fallas.
(2005-05-09)
El paquete ahora incluye un conjunto de documentación de referencia que consta de páginas de manual con formato HTML estilo Unix que se han editado para mantener la coherencia con pthreads-win32. El conjunto también se puede leer en línea en: http://sources.redhat.com/pthreads-win32/manual/index.html
Gracias nuevamente a Tim Theisen por ejecutar la versión preliminar del conjunto de pruebas en un sistema MP.
Todas las correcciones de errores y las nuevas funciones de esta versión se han adaptado a la versión 1.9.0.
La implementación modificada evita la necesidad del problemático HANDLE y recupera la memoria tan pronto como se elimina la clave O el hilo sale, lo que ocurra primero.
Gracias a Richard Hughes de Aculab por identificar y localizar la fuga.
Los destructores de claves TSD ahora se procesan hasta PTHREAD_DESTRUCTOR_ITERATION veces en lugar de solo una vez. PTHREAD_DESTRUCTOR_ITERATION se ha definido en pthread.h durante algún tiempo pero no se ha utilizado.
Se corrigió una carrera de contabilidad de semáforos entre sem_post/sem_post_multiple y la cancelación de sem_wait. Este es el mismo problema que con sem_timedwait que se solucionó en la última versión.
sem_init, sem_post y sem_post_multiple ahora verifican que el recuento de semáforos nunca exceda _POSIX_SEM_VALUE_MAX.
Aunque sigwait() no es más que una operación no operativa, al menos debería ser un punto de cancelación para ser coherente con el estándar.
estrés1.c: intenta exponer problemas en la variable de condición y la lógica de espera temporizada del semáforo. Esta prueba se inspiró en el código de prueba de muestra de Stephan Mueller utilizado para identificar el error sem_timedwait de la última versión. No forma parte del conjunto de pruebas habitual porque puede tardar un poco en ejecutarse. Para ejecutarlo: nmake clean VC-stress
tsd2.c: prueba que los destructores de claves se vuelven a ejecutar si el valor de la clave tsd no es NULL después de que se haya ejecutado la rutina del destructor. También prueba que pthread_setspecific() y pthread_getspecific() son invocables desde destructores.
(26 de abril de 2005)
Ahora no hay ningún plan para lanzar una versión 3.0.0 para solucionar problemas en pthread_once(). Se seguirán investigando otras posibles implementaciones de pthread_once para una posible versión futura en un intento de reducir la complejidad de la implementación actual.
Todas las correcciones de errores y las nuevas funciones de esta versión se han adaptado a la versión 1.8.0.
Se corrigió la carrera pthread_once (fallas en un sistema MP). Gracias a Tim Theisen por realizar pruebas exhaustivas de prelanzamiento en su sistema MP utilizando una variedad de compiladores: VC++ 6 VC++ 7.1 Intel C++ versión 8.0 Todas las pruebas pasaron. También se realizaron algunas mejoras menores en la velocidad.
Se corrigió el error de desbordamiento de enteros en pthread_mutex_timedlock(); se perdió cuando sem_timedwait() se corrigió en la versión 2.2.0. Esta rutina ya no devuelve ENOTSUP cuando se define NEED_SEM; es compatible (NEED_SEM solo se requiere para versiones de WinCE anteriores a 3.0).
Se corrigió el error de tiempo de espera en sem_timedwait().
Solucione varios problemas en el código NEED_SEM incluido condicionalmente. El código incluido NEED_SEM se proporciona para sistemas que no implementan semáforos W32, como WinCE antes de la versión 3.0. Se crea una implementación alternativa de semáforos POSIX utilizando eventos W32 para estos sistemas cuando se define NEED_SEM. Este código se ha reescrito completamente en esta versión para reutilizar la mayor parte del código de semáforo POSIX predeterminado y, en particular, para implementar todas las rutinas sem_* admitidas por pthreads-win32. Tim Theisen también ejecutó el conjunto de pruebas sobre el código NEED_SEM en su sistema MP. Todas las pruebas pasaron.
La biblioteca ahora se compila sin errores para el compilador Borland Builder 5.5.
pthread_once es demasiado complicado, pero funciona hasta donde las pruebas pueden determinar.
La versión Borland de la DLL falla algunas de las pruebas con una excepción de lectura de memoria. Aún no se conoce la causa, pero no se ha descartado un error del compilador.
(2005-04-12)
La versión 1.7.0 es una versión anterior de funciones y correcciones de errores nuevas en esta versión. Consulte las notas anteriores en la Versión 2.0.0/General.
(2005-04-04)
Se agregaron destinos de archivos MAKE para crear versiones de enlaces estáticos de la biblioteca. Tanto MinGW como MSVC. Tenga en cuenta que esto no implica ningún cambio en la licencia LGPL, que aún impone condiciones específicas sobre la distribución de software que ha sido vinculado estáticamente con esta biblioteca.
Hay un error conocido en pthread_once(). La cancelación de init_routine expone un posible problema de inanición (es decir, punto muerto) si un subproceso en espera tiene una prioridad más alta que el subproceso inicial. Este problema se solucionará en la versión 3.0.0 de la biblioteca.
Se corrigió el error de desbordamiento de enteros en sem_timedwait(). Kevin Lussier
Se corrigieron las directivas del preprocesador para enlaces estáticos. Dimitar Panayotov
(2005-03-16)
(2005-03-16)
Esta versión representa un cambio de ABI y el nombre de la versión de DLL se ha incrementado de 1 a 2, por ejemplo, pthreadVC2.dll.
La versión 1.4.0 incorpora la nueva funcionalidad incluida en esta versión. Distribuya las DLL creadas a partir de esa versión con actualizaciones para las aplicaciones creadas en pthreads-win32 versión 1.xx.
El nombre del paquete ha cambiado, reemplazando la fecha de la instantánea con el número de versión + información descriptiva. Por ejemplo, esta versión es "pthreads-win32-2-0-0-release".
Versión 1.3.0
Versión 1.2.0
Versión 1.1.0
Versión 1.0.0
Esta instantánea arregla principalmente el error de Condvar introducido en la instantánea 2004-11-03. También se ha incluido el versiones de DLL para permitir que las aplicaciones se ejecuten el tiempo de ejecución de la información de versión DLL compatible con Microsoft, y para extender el sistema de nombres de DLL para los cambios API ABI y los principales (no compatibles con compatibilidad). Vea el archivo ReadMe para obtener más detalles.
Se ha agregado un recurso de versión de estilo Microsoft a la DLL para aplicaciones que desean verificar la compatibilidad de DLL en tiempo de ejecución.
El nombre de DLL PTHREADS-WIN32 se ha extendido para permitir que las versiones DLL incompatibles coexistan en el mismo sistema de archivos. Consulte el archivo ReadMe para obtener detalles, pero brevemente: si bien la información de la versión dentro de la DLL cambiará con cada versión a partir de ahora, los nombres de versión de DLL solo cambiarán si el nuevo DLL no es compatible con las aplicaciones más antiguas.
El esquema de versiones se ha tomado de GNU LBTOOL, y el esquema de nombres DLL es de Cygwin. Siempre que se honren las reglas de numeración de estilo LibTool, el esquema de nomenclatura de Cygwin DLL garantiza automáticamente que los cambios de nombre de DLL sean mínimos y que las aplicaciones no cargarán una dll incompatible de PTHREADS-WIN32.
Aquellos que usan las DLL prebujadas encontrarán que los nombres DLL/LIB tienen un nuevo sufijo (1) en esta instantánea. Por ejemplo, pthreadvc1.dll etc.
Ciertas macros Posix han cambiado.
Estos cambios están destinados a ajustarse a la única especificación de UNIX versión 3, que establece que, si se establece en 0 (cero) o no definido, las aplicaciones pueden usar sysconf () para determinar sus valores en tiempo de ejecución. pthreads-win32 no implementa sysconf ().
Las siguientes macros ya no están indefinidas, sino definidas y establecidas en -1 (no implementadas):
_POSIX_THREAD_ATTR_STACKADDR
_POSIX_THREAD_PRIO_INHERIT
_POSIX_THREAD_PRIO_PROTECT
_POSIX_THREAD_PROCESS_SHARED
Las siguientes macros se definen y se establecen en 200112L (implementado):
_POSIX_THREADS
_POSIX_THREAD_SAFE_FUNCTIONS
_POSIX_THREAD_ATTR_STACKSIZE
_POSIX_THREAD_PRIORITY_SCHEDULING
_POSIX_SEMAPHORES
_POSIX_READER_WRITER_LOCKS
_POSIX_SPIN_LOCKS
_POSIX_BARRIERS
Las siguientes macros se definen y se establecen en los valores apropiados:
_POSIX_THREAD_THREADS_MAX
_POSIX_SEM_VALUE_MAX
_POSIX_SEM_NSEMS_MAX
PTHREAD_DESTRUCTOR_ITERATIONS
PTHREAD_KEYS_MAX
PTHREAD_STACK_MIN
PTHREAD_THREADS_MAX
Las DLL producidas a partir de esta instantánea no se pueden usar con aplicaciones más antiguas sin recompensar la aplicación, debido a un cambio en pthread_t para proporcionar ID de hilo POSIX únicos.
Aunque esta instantánea pasa la suite de prueba extendida, muchos de los cambios son bastante importantes, y algunas aplicaciones pueden mostrar un comportamiento diferente que antes, por lo que adopta con cuidado. Con suerte, cualquier comportamiento cambiado se debió a que la biblioteca es mejor en su trabajo, no peor.
pthread_create () ya no acepta nulo como la referencia de hilo Arg. Se producirá un SEGFault (falla de acceso a la memoria), y no se creará ningún hilo.
pthread_barrier_wait () ya no actúa como un punto de cancelación.
Arregle la condición de carrera potencial en pthread_once ()
Agregado para compatibilidad: pthread_recursive_mutex_initializer, pthread_errorcheck_mutex_initializer, pthread_recursive_mutex_initializer_np, pthread_errorcheck_mutex_initializer_np
Soporte inicial para el compilador digital de Marte
Mutexes más rápidos. Estos se han reescrito después de un modelo proporcionado por Alexander Terekhov que reduce las controles espaciales del núcleo, y elimina algunas secciones críticas adicionales utilizadas para administrar una carrera entre la expiración y el desbloqueo de Timedlock. Tenga en cuenta que los nuevos mutexes no aplican una programación de mutexes absoluta estricta de mutexes, sin embargo, cualquier adquisición de bloqueo fuera de orden debería ser muy rara.
Semáforos más rápidos. Siguiendo un modelo similar a los mutexes anteriores, estos se han reescrito para utilizar las verificaciones de espacio de usuarios preliminares.
SEM_GETVALUE () ahora devuelve el número de camareros.
La identificación del hilo POSIX ahora tiene características de singularidad mucho más fuertes. La biblioteca Garrantes no reutiliza la misma identificación de hilo para al menos 2^(palabras) ciclos de destrucción/creación de hilos.
Semaphore4.c: prueba la cancelación del nuevo SEM_WAIT ().
SEMAPHORE4T.C: Del mismo modo para SEM_TIMEDWAIT ().
RWLOCK8.C: Prueba y veces las rutas de ejecución lenta de los bloqueos R/W, y los CV, mutexes y semáforos en los que se basan.
Intente agregar Watcom a la lista de compiladores que puedan construir la biblioteca. Esto falló al final debido a su error no consciente de los thread. La biblioteca se construye pero la suite de prueba falla. Consulte ReadMe.watcom para más detalles.
Nota: Si no usa la cancelación de Async en su aplicación, o no necesita cancelar los subprocesos que están bloqueados en los recursos del sistema, como la E/S de la red, entonces la cancelación de asíncrono no preventiva predeterminada es probablemente lo suficientemente bueno. Sin embargo, PTHREADS-WIN32 Auto detecta la disponibilidad de estos componentes en tiempo de ejecución, por lo que no necesita reconstruir la biblioteca de la fuente si cambia de opinión más adelante.
Todos los consejos disponibles en los libros y en otras partes de la indesiabilidad del uso de la cancelación de Async en cualquier aplicación sigue en pie, pero esta característica es una adición bienvenida con respecto a la conformidad de la biblioteca con el estándar POSIX.
Limpieza de la gestión de prioridad del hilo. En particular, la configuración de la prioridad del subproceso ahora intenta mapear los valores de Win32 inválidos dentro del rango devuelto por SHET_GET_PRIORITY_MIN/MAX () a valores útiles. Consulte ReadMe.nonportable bajo "Prioridad del hilo".
pthread_getschedparam () ahora devuelve la prioridad dada por la llamada más reciente a pthread_setschedparam () o establecida por pthread_create (), según lo requiera el estándar. Anteriormente, pthread_getschedparam () devolvió incorrectamente la prioridad del hilo en ejecución en el momento de la llamada, que puede haber sido ajustado o promovido temporalmente.
sched_get_priority_min () y sched_get_priority_max () ahora retrocede -1 en el error y establece errno. Anteriormente, devolvieron incorrectamente el valor de error directamente.
pthread_self () liberaría el mango de hilo POSIX implícito recién creado si DuplateHandle falló en lugar de reciclarlo (muy poco probable).
pthread_exit () no fue liberador ni reciclaje de la estructura de hilos POSIX para hilos POSIX implícitos.
Desde la implementación original de John Bossom, la biblioteca ha permitido que los hilos inicializados no positivos (hilos Win32) llamen a rutinas PTHREADS-WIN32 y, por lo tanto, interactúen con los hilos POSIX. Esto se hace creando una ID de hilo POSIX sobre la marcha para el hilo Win32 que, una vez creado, permite una interacción totalmente recectada. Esto no se extendió a la cancelación de subprocesos (async o diferido). Ahora lo hace.
Cualquier hilo puede ser cancelado por cualquier otro hilo (Win32 o POSIX) si se conoce el valor POSIX PTHREAD_T del hilo del antiguo hilo del antiguo anterior. Son los destructores TSD y los manejadores de limpieza POSIX se ejecutarán antes de que el hilo salga con un código de salida de pthread_canceled (recuperado con getExitCodethread ()).
Esto permite que un hilo Win32, por ejemplo, llame a las rutinas CV POSIX de la misma manera que los hilos Posix/deberían, con PTHREAD_COND_WAIT () Cancelabilidad y controladores de limpieza (pthread_cond_wait () es un punto de cancelación POSIX).
Al agregar cancelación, los hilos Win32 ahora deberían poder llamar a todas las rutinas de los hilos de Posix que tienen sentido, incluidos semáforos, mutexes, variables de condición, bloqueos de lectura/escritura, barreras, hilvanados, TSD, empuje de limpieza/pop, cancelación, pthread_exit, programación, programación, etc. .
Tenga en cuenta que estos ID de hilo POSIX 'implícitos' sobre la marcha se inicializan como separados (no unidos) con el tipo de cancelación diferida. El ID del subproceso POSIX será creado automáticamente por cualquier rutina POSIX que necesite un mango POSIX (a menos que la rutina necesite un PTHREAD_T como parámetro, por supuesto). Un hilo Win32 puede descubrir su propia ID de hilo POSIX llamando a pthread_self (), que creará el mango si es necesario y devolverá el valor pthread_t.
Pruebe la nueva característica anterior.
Esta instantánea soluciona una corrupción accidental a las nuevas fuentes de casos de prueba. No hay cambios en el código fuente de la biblioteca.
Varios cambios para endurecer la verificación ARG y trabajar con versiones posteriores de Mingw32 y Msysdtk.
pthread_getschedparam () etc, comprobación de validez de hilo peligrosa fija fija.
SEM_TIMEDWAIT () ahora utiliza verificaciones más estrictas para valores de abstime irrazonables, lo que daría como resultado valores de tiempo de espera inesperados.
PTW32_COND_WAIT_CLEANUP () ya no consume señales de CV misteriosamente, sino que puede producir despertadores más espurios. Se cree que la llamada SEM_TIMEDWAIT () está consumiendo una señal CV que no debería.
Se corrigió una fuga de memoria en PTW32_ThreadDestroy () para hilos implícitos.
Se corrigió el potencial para el punto muerto en pthread_cond_destroy (). Un punto muerto podría ocurrir para CVS declarado estáticamente (pthread_cond_initializer), cuando un hilo intenta destruir la variable de condición mientras que otro intenta inicializar dinámicamente.
Anteriormente, si no se definió, el estilo de limpieza se determinó automáticamente desde el compilador/idioma, y uno de los siguientes se definió en consecuencia:
PTW32_CLEANUP_SEH MSVC only
PTW32_CLEANUP_CXX C++, including MSVC++, GNU G++
PTW32_CLEANUP_C C, including GNU GCC, not MSVC
Estas define determinan el estilo de limpieza (ver pThread.h) y, lo más importante, se realiza la forma en que se realiza la cancelación y la salida de subprocesos (a través de pthread_exit) (consulte la rutina PTW32_Throw () en private.c).
En resumen, las versiones de excepciones de la biblioteca arrojan una excepción cuando se cancela un hilo o sale (a través de pthread_exit ()), que es atrapado por un controlador en la rutina de inicio del hilo, de modo que el relajado de la pila correcta ocurra independientemente de dónde El hilo es cuando se cancela o sale a través de pthread_exit ().
En esta y futuras instantáneas, a menos que la compilación define explícitamente (por ejemplo, a través de una opción de compilador) ptw32_cleanup_seh, ptw32_cleanup_cxx o ptw32_cleanup_c, entonces la compilación ahora siempre es predeterminada a ptw32_cleanup_c estilo limpieza. Este estilo usa SetJMP/LongJMP en las implementaciones de cancelación y PTHRead_Exit, y por lo tanto no hará el relajado de la pila incluso cuando se vinculan a aplicaciones que lo tienen (p. Ej. Aplicaciones C ++). Esto es para la consistencia con la mayoría de las implementaciones actuales de hilos comerciales de UNIX POSIX. El TRU64 de Compaq puede ser una excepción (sin juego de palabras) y posible tendencia futura.
Aunque no estaba claramente documentado antes, todavía es necesario construir su aplicación utilizando el mismo PTW32_Cleanup_* Definir como se usó para la versión de la biblioteca con la que se vincula, de modo que se incluyan las partes correctas de pthread.h. Es decir, las posibles define requieren las siguientes versiones de la biblioteca:
PTW32_CLEANUP_SEH pthreadVSE.dll
PTW32_CLEANUP_CXX pthreadVCE.dll or pthreadGCE.dll
PTW32_CLEANUP_C pthreadVC.dll or pthreadGC.dll
Por ejemplo, independientemente de si su aplicación es C o C ++, si se vincula con pthreadvc.lib o libpThreadgc.a, entonces debe definir PTW32_Cleanup_C.
El punto de todo esto es: si no ha estado definiendo uno de estos explícitamente, entonces se usaron los valores predeterminados como se describen en la parte superior de esta sección.
Esto ahora cambia, como se ha explicado anteriormente, pero para tratar de aclarar esto aquí hay un ejemplo:
Si estaba construyendo su aplicación con MSVC ++, es decir, usando excepciones de C ++ y no definió explícitamente una de PTW32_Cleanup_*, entonces PTW32_Cleanup_C ++ se definió automáticamente para usted en pthread.h. Debería haber estado vinculando con pthreadvce.dll, que se relaja.
Si ahora crea su aplicación como lo había hecho antes, pthread.h ahora configurará automáticamente PTW32_CLEANUP_C como el estilo predeterminado, y deberá vincular con pthreadvc.dll. El relajado de la pila ahora no ocurrirá cuando se cancele un hilo, o el hilo llama pthread_exit ().
Su aplicación ahora probablemente se comportará de manera diferente a las versiones anteriores y de manera no obvia. Lo más probable es que los objetos instanciados localmente no sean destruidos o limpiados después de cancelar un hilo.
Si desea el mismo comportamiento que antes, ahora debe definir PTW32_CLEANUP_C ++ explícitamente usando una opción de compilador y un enlace con pthreadvce.dll como lo hizo antes.
¿Por qué estamos haciendo que el estilo predeterminado sea menos amigable con las excepciones? Porque ninguna implementación comercial de los hilos de POSIX UNIX le permite elegir relajarse de la pila. Por lo tanto, proporcionarlo en pthread-win32 como predeterminado es peligroso. Todavía proporcionamos la opción, pero a menos que elija conscientemente hacer lo contrario, sus aplicaciones PTHreads ahora se ejecutarán o bloquearán de manera similar, independientemente de la plataforma Threads que use. O al menos esta es la esperanza.
¿Por qué no eliminar las versiones de excepciones de la biblioteca por completo? Hay algunas razones:
Para habilitar los tamaños de imagen más pequeños que se generan para aplicaciones que enlazan estáticamente con la biblioteca, la mayoría de las rutinas se han separado en archivos de código fuente individuales.
Esto se está haciendo de tal manera que sea compatible con retroceso. Los archivos de origen antiguos se reutilizan para congregar los archivos de rutina individuales en unidades de traducción más grandes (a través de un montón de #includes) para que el compilador aún pueda optimizar siempre que sea posible, por ejemplo, a través de la inscripción, que solo se puede hacer dentro de la misma unidad de traducción.
También es posible construir toda la biblioteca compilando el solo archivo llamado "pthread.c", que solo #incluye todos los archivos de origen de la congregación secundaria. El compilador puede usar esto para hacer más engrasamiento de las rutinas.
Aunque el compilador GNU puede producir bibliotecas con la separación necesaria (el interruptor de segmentos -function), AFAIK, MSVC y otros compiladores no tienen esta característica.
Finalmente, dado que uso Makefiles y Command-Line Compilation, no sé qué estragos esta reorganización puede causar entre los usuarios de archivos del proyecto IDE. Debería poder continuar utilizando sus archivos de proyecto existentes sin modificación.
pthread_num_processors_np ():
Devuelve el número de procesadores en el sistema que están disponibles para el proceso, según lo determinado de la máscara de afinidad del procesador.
pthread_timechange_handler_np ():
Para mejorar la tolerancia contra los cambios de reloj del sistema iniciados por el operador o el servicio de tiempo.
Una aplicación puede llamar a esta rutina cuando recibe un mensaje WM_TIMECHANGE del sistema. En la actualidad, transmite todas las variables de condición para que los hilos de espera puedan despertarse y reevaluar sus condiciones y reiniciar sus esperas cronometradas si es necesario.
Como Win95 no proporciona uno, la biblioteca ahora contiene su propia rutina InterlockedComPareExchange (), que se usa cuando Windows no lo proporciona. InterlockedCompareExchange () se utiliza para implementar spinlocks y barreras, y también en mutexes. Esta rutina se basa en la instrucción de la máquina CMPXCHG que no está disponible en las CPU i386. Por lo tanto, esta biblioteca (desde Snapshot 20010712 en adelante) ya no es compatible con las plataformas de procesadores I386.
Solo para la portabilidad del código fuente: los rwlocks no pueden ser compartidos todavía.
pthread_rwlockattr_init()
pthread_rwlockattr_destroy()
pthread_rwlockattr_setpshared()
pthread_rwlockattr_getpshared()
Como se define en el nuevo estándar POSIX, y la única especificación de UNIX versión 3:
sem_timedwait()
pthread_mutex_timedlock() - Alexander Terekhov and Thomas Pfaff
pthread_rwlock_timedrdlock() - adapted from pthread_rwlock_rdlock()
pthread_rwlock_timedwrlock() - adapted from pthread_rwlock_wrlock()
[Todavía no para G ++]
Esto se hizo para evitar conflictos.
Manejar, dWord y null se definen temporalmente dentro de pthread.h si aún no lo están.
No solo para evitar la necesidad del archivo pthread.def, sino para mejorar el rendimiento. Aparentemente, declarar las funciones con Dllimport genera una llamada directa a la función y evita la sobrecarga de una llamada de función Stub.
Esto podría hacerse transparente a las aplicaciones reemplazando las macros que definen las versiones actuales de C ++ y SEH de pthread_cleanup_push/pop con la versión C, pero los manejadores de limpieza AFAIK no ejecutarían en la secuencia correcta con destructores y manejadores de limpieza de excepción cuando se produce una excepción cuando ocurre una excepción cuando ocurre una excepción. .
La cancelación una vez que se inició en un hilo ahora no se puede cancelar doble inadvertidamente. Es decir, una vez que comience un hilo, su ejecución de cancelación, la cancelación está deshabilitada y una solicitud de cancelación posterior devolverá un error (ESRCH).
ERRNO: una directiva de compilador incorrecto causó que se usara una versión local de ERRNO en lugar del Win32 errno. Ambas instancias son seguras de hilo, pero las aplicaciones verifican errno después de una llamada pThreads-win32 estarían mal. La fijación de esto también se corrigió una opción de compilador malo en TestSuite ( /MT debería haber sido /MD) que es necesario para vincular con la biblioteca correcta msvcrt.lib.
Para ser agregado
Para ser agregado
Nuevo:
Renamed DLL and LIB files:
pthreadVSE.dll (MS VC++/Structured EH)
pthreadVSE.lib
pthreadVCE.dll (MS VC++/C++ EH)
pthreadVCE.lib
pthreadGCE.dll (GNU G++/C++ EH)
libpthreadw32.a
Both your application and the pthread dll should use the
same exception handling scheme.
Errores solucionados:
MSVC++ C++ exception handling.
Se han agregado algunas nuevas pruebas.
Nuevo:
asynchronous cancellation on X86 (Jason Nye)
Makefile compatible with MS nmake to replace
buildlib.bat
GNUmakefile for Mingw32
tests/Makefile for MS nmake replaces runall.bat
tests/GNUmakefile for Mingw32
Errores solucionados:
kernel32 load/free problem
attempt to hide internel exceptions from application
exception handlers (__try/__except and try/catch blocks)
Win32 thread handle leakage bug
(David Baggett/Paul Redondo/Eyal Lebedinsky)
Se han agregado algunas nuevas pruebas.
Errores solucionados:
ctime_r macro had an incorrect argument (Erik Hensema),
threads were not being created
PTHREAD_CANCEL_DEFERRED. This should have
had little effect as deferred is the only
supported type. (Ross Johnson).
Algunas mejoras de compatibilidad agregadas, por ejemplo.
pthread_setcancelstate accepts NULL pointer
for the previous value argument. Ditto for
pthread_setcanceltype. This is compatible
with Solaris but should not affect
standard applications (Erik Hensema)
Se han agregado algunas nuevas pruebas.
Corrección de errores: la cancelación de los hilos que esperan las variables de condición ahora funciona correctamente (Lorin Hochstein y Peter Slacik)
Se corrigió la limpieza de la pila de excepciones si llamaba a pthread_exit ()
Se corrigieron los errores en las variables de condición - (Peter Slacik): - Comprobaciones de contención adicionales - Ajuste correctamente el número de subprocesos de espera después del tiempo de espera cronometrado de Condvar.
Se han solucionado algunos errores menores. Consulte el archivo ChangeLog para obtener más detalles.
Ahora se incluyen algunas funciones más POSIX 1B, pero en Ony devuelve un error (ENOSYS) si se llama. Ellos son:
sem_open
sem_close
sem_unlink
sem_getvalue
Algunas funciones POSIX 1B que fueron compatibles internamente ahora están disponibles como funciones exportadas:
sem_init
sem_destroy
sem_wait
sem_trywait
sem_post
sched_yield
sched_get_priority_min
sched_get_priority_max
Se han solucionado algunos errores menores. Consulte el archivo ChangeLog para obtener más detalles.
Liberación inicial.