-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathNEWS
1241 lines (921 loc) · 41.2 KB
/
NEWS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
RELEASE 2.9.0
-------------
(2012-05-25)
General
-------
New bug fixes in this release since 2.8.0 have NOT been applied to the
1.x.x series.
Some changes post 2011-02-26 in CVS may not be compatible with pre
Windows 2000 systems.
Use of other than the "C" version of the library is now discouraged.
That is, the "C++" version fails some tests and does not provide any
additional functionality.
Testing and verification
------------------------
This version has been tested on SMP architecture (Intel x64 Hex Core)
by completing the included test suite, stress and bench tests.
New Features
------------
DLL properties now properly includes the target architecture, i.e.
right-click on the file pthreadVC2.dll in explorer and choose the Detail
tab will show the compiler and architecture in the description field, e.g.
"MS C x64" or "MS C x86".
- Ross Johnson
(MSC and GNU builds) The statically linked library now automatically
initialises and cleans up on program start/exit, i.e. statically linked
applications need not call the routines pthread_win32_process_attach_np()
and pthread_win32_process_detach_np() explicitly. The per-thread routine
pthread_win32_thread_detach_np() is also called at program exit to cleanup
POSIX resources acquired by the primary Windows native thread, if I (RJ)
understand the process correctly. Other Windows native threads that call
POSIX API routines may need to call the thread detach routine on thread
exit if the application depends on reclaimed POSIX resources or running
POSIX TSD (TLS) destructors.
See README.NONPORTABLE for descriptions of these routines.
- Ramiro Polla
Robust mutexes are implemented within the PROCESS_PRIVATE scope. NOTE that
pthread_mutex_* functions may return different error codes for robust
mutexes than they otherwise do in normal usage, e.g. pthread_mutex_unlock
is required to check ownership for all mutex types when the mutex is
robust, whereas this does not occur for the "normal" non-robust mutex type.
- Ross Johnson
pthread_getunique_np is implemented for source level compatibility
with some other implementations. This routine returns a 64 bit
sequence number that is uniquely associated with a thread. It can be
used by applications to order or hash POSIX thread handles.
- Ross Johnson
Bug fixes
---------
Many more changes for 64 bit systems.
- Kai Tietz
Various modifications and fixes to build and test for WinCE.
- Marcel Ruff, Sinan Kaya
Fix pthread_cond_destroy() - should not be a cancellation point. Other
minor build problems fixed.
- Romano Paolo Tenca
Remove potential deadlock condition from pthread_cond_destroy().
- Eric Berge
Various modifications to build and test for Win64.
- Kip Streithorst
Various fixes to the QueueUserAPCEx async cancellation helper DLL
(this is a separate download) and pthreads code cleanups.
- Sebastian Gottschalk
Removed potential NULL pointer reference.
- Robert Kindred
Removed the requirement that applications restrict the number of threads
calling pthread_barrier_wait to just the barrier count. Also reduced the
contention between barrier_wait and barrier_destroy. This change will have
slowed barriers down slightly but halves the number of semaphores consumed
per barrier to one.
- Ross Johnson
Fixed a handle leak in sched_[gs]etscheduler.
- Mark Pizzolato
Removed all of the POSIX re-entrant function compatibility macros from pthread.h.
Some were simply not semanticly correct.
- Igor Lubashev
Threads no longer attempt to pass uncaught exceptions out of thread scope (C++
and SEH builds only). Uncaught exceptions now cause the thread to exit with
the return code PTHREAD_CANCELED.
- Ross Johnson
Lots of casting fixes particularly for x64, Interlocked fixes and reworking
for x64.
- Daniel Richard G., John Kamp
Other changes
-------------
Dependence on the winsock library is now discretionary via
#define RETAIN_WSALASTERROR in config.h. It is undefined by default unless
WINCE is defined (because RJ is unsure of the dependency there).
- Ramiro Polla
Several static POSIX mutexes used for internal management were replaced by
MCS queue-based locks to reduce resource consumption, in particular use of Win32
objects.
- Ross Johnson
For security, the QuserEx.dll if used must now be installed in the Windows System
folder.
- Ross Johnson
New tests
---------
robust[1-5].c - Robust mutexes
sequence1.c - per-thread unique sequence numbers
Modified tests and benchtests
-----------------------------
All mutex*.c tests wherever appropriate have been modified to also test
robust mutexes under the same conditions.
Added robust mutex benchtests to benchtest*.c wherever appropriate.
RELEASE 2.8.0
-------------
(2006-12-22)
General
-------
New bug fixes in this release since 2.7.0 have not been applied to the
version 1.x.x series. It is probably time to drop version 1.
Testing and verification
------------------------
This release has not yet been tested on SMP architechtures. All tests pass
on a uni-processor system.
Bug fixes
---------
Sem_destroy could return EBUSY even though no threads were waiting on the
semaphore. Other races around invalidating semaphore structs (internally)
have been removed as well.
New tests
---------
semaphore5.c - tests the bug fix referred to above.
RELEASE 2.7.0
-------------
(2005-06-04)
General
-------
All new features in this release have been back-ported in release 1.11.0,
including the incorporation of MCS locks in pthread_once, however, versions
1 and 2 remain incompatible even though they are now identical in
performance and functionality.
Testing and verification
------------------------
This release has been tested (passed the test suite) on both uni-processor
and multi-processor systems.
- Tim Theisen
Bug fixes
---------
Pthread_once has been re-implemented to remove priority boosting and other
complexity to improve robustness. Races for Win32 handles that are not
recycle-unique have been removed. The general form of pthread_once is now
the same as that suggested earlier by Alexander Terekhov, but instead of the
'named mutex', a queue-based lock has been implemented which has the required
properties of dynamic self initialisation and destruction. This lock is also
efficient. The ABI is unaffected in as much as the size of pthread_once_t has
not changed and PTHREAD_ONCE_INIT has not changed, however, applications that
peek inside pthread_once_t, which is supposed to be opaque, will break.
- Vladimir Kliatchko
New features
------------
* Support for Mingw cross development tools added to GNUmakefile.
Mingw cross tools allow building the libraries on Linux.
- Mikael Magnusson
RELEASE 2.6.0
-------------
(2005-05-19)
General
-------
All of the bug fixes and new features in this release have been
back-ported in release 1.10.0.
Testing and verification
------------------------
This release has been tested (passed the test suite) on both uni-processor
and multi-processor systems. Thanks to Tim Theisen at TomoTherapy for
exhaustively running the MP tests and for providing crutial observations
and data when faults are detected.
Bugs fixed
----------
* pthread_detach() now reclaims remaining thread resources if called after
the target thread has terminated. Previously, this routine did nothing in
this case.
New tests
---------
* detach1.c - tests that pthread_detach properly invalidates the target
thread, which indicates that the thread resources have been reclaimed.
RELEASE 2.5.0
-------------
(2005-05-09)
General
-------
The package now includes a reference documentation set consisting of
HTML formatted Unix-style manual pages that have been edited for
consistency with Pthreads-w32. The set can also be read online at:
http://sources.redhat.com/pthreads-win32/manual/index.html
Thanks again to Tim Theisen for running the test suite pre-release
on an MP system.
All of the bug fixes and new features in this release have been
back-ported in release 1.9.0.
Bugs fixed
----------
* Thread Specific Data (TSD) key management has been ammended to
eliminate a source of (what was effectively) resource leakage (a HANDLE
plus memory for each key destruct routine/thread association). This was
not a true leak because these resources were eventually reclaimed when
pthread_key_delete was run AND each thread referencing the key had exited.
The problem was that these two conditions are often not met until very
late, and often not until the process is about to exit.
The ammended implementation avoids the need for the problematic HANDLE
and reclaims the memory as soon as either the key is deleted OR the
thread exits, whichever is first.
Thanks to Richard Hughes at Aculab for identifying and locating the leak.
* TSD key destructors are now processed up to PTHREAD_DESTRUCTOR_ITERATIONS
times instead of just once. PTHREAD_DESTRUCTOR_ITERATIONS has been
defined in pthread.h for some time but not used.
* Fix a semaphore accounting race between sem_post/sem_post_multiple
and sem_wait cancellation. This is the same issue as with
sem_timedwait that was fixed in the last release.
* sem_init, sem_post, and sem_post_multiple now check that the
semaphore count never exceeds _POSIX_SEM_VALUE_MAX.
* Although sigwait() is nothing more than a no-op, it should at least
be a cancellation point to be consistent with the standard.
New tests
---------
* stress1.c - attempts to expose problems in condition variable
and semaphore timed wait logic. This test was inspired by Stephan
Mueller's sample test code used to identify the sem_timedwait bug
from the last release. It's not a part of the regular test suite
because it can take awhile to run. To run it:
nmake clean VC-stress
* tsd2.c - tests that key destructors are re-run if the tsd key value is
not NULL after the destructor routine has run. Also tests that
pthread_setspecific() and pthread_getspecific() are callable from
destructors.
RELEASE 2.4.0
-------------
(2005-04-26)
General
-------
There is now no plan to release a version 3.0.0 to fix problems in
pthread_once(). Other possible implementations of pthread_once
will still be investigated for a possible future release in an attempt
to reduce the current implementation's complexity.
All of the bug fixes and new features in this release have been
back-ported for release 1.8.0.
Bugs fixed
----------
* Fixed pthread_once race (failures on an MP system). Thanks to
Tim Theisen for running exhaustive pre-release testing on his MP system
using a range of compilers:
VC++ 6
VC++ 7.1
Intel C++ version 8.0
All tests passed.
Some minor speed improvements were also done.
* Fix integer overrun error in pthread_mutex_timedlock() - missed when
sem_timedwait() was fixed in release 2.2.0. This routine no longer returns
ENOTSUP when NEED_SEM is defined - it is supported (NEED_SEM is only
required for WinCE versions prior to 3.0).
* Fix timeout bug in sem_timedwait().
- Thanks to Stephan Mueller for reporting, providing diagnostic output
and test code.
* Fix several problems in the NEED_SEM conditionally included code.
NEED_SEM included code is provided for systems that don't implement W32
semaphores, such as WinCE prior to version 3.0. An alternate implementation
of POSIX semaphores is built using W32 events for these systems when
NEED_SEM is defined. This code has been completely rewritten in this
release to reuse most of the default POSIX semaphore code, and particularly,
to implement all of the sem_* routines supported by pthreads-win32. Tim
Theisen also run the test suite over the NEED_SEM code on his MP system. All
tests passed.
* The library now builds without errors for the Borland Builder 5.5 compiler.
New features
------------
* pthread_mutex_timedlock() and all sem_* routines provided by
pthreads-win32 are now implemented for WinCE versions prior to 3.0. Those
versions did not implement W32 semaphores. Define NEED_SEM in config.h when
building the library for these systems.
Known issues in this release
----------------------------
* pthread_once is too complicated - but it works as far as testing can
determine..
* The Borland version of the dll fails some of the tests with a memory read
exception. The cause is not yet known but a compiler bug has not been ruled
out.
RELEASE 2.3.0
-------------
(2005-04-12)
General
-------
Release 1.7.0 is a backport of features and bug fixes new in
this release. See earlier notes under Release 2.0.0/General.
Bugs fixed
----------
* Fixed pthread_once potential for post once_routine cancellation
hanging due to starvation. See comments in pthread_once.c.
Momentary priority boosting is used to ensure that, after a
once_routine is cancelled, the thread that will run the
once_routine is not starved by higher priority waiting threads at
critical times. Priority boosting occurs only AFTER a once_routine
cancellation, and is applied only to that once_control. The
once_routine is run at the thread's normal base priority.
New tests
---------
* once4.c: Aggressively tests pthread_once() under realtime
conditions using threads with varying priorities. Windows'
random priority boosting does not occur for threads with realtime
priority levels.
RELEASE 2.2.0
-------------
(2005-04-04)
General
-------
* Added makefile targets to build static link versions of the library.
Both MinGW and MSVC. Please note that this does not imply any change
to the LGPL licensing, which still imposes psecific conditions on
distributing software that has been statically linked with this library.
* There is a known bug in pthread_once(). Cancellation of the init_routine
exposes a potential starvation (i.e. deadlock) problem if a waiting thread
has a higher priority than the initting thread. This problem will be fixed
in version 3.0.0 of the library.
Bugs fixed
----------
* Fix integer overrun error in sem_timedwait().
Kevin Lussier
* Fix preprocessor directives for static linking.
Dimitar Panayotov
RELEASE 2.1.0
-------------
(2005-03-16)
Bugs fixed
----------
* Reverse change to pthread_setcancelstate() in 2.0.0.
RELEASE 2.0.0
-------------
(2005-03-16)
General
-------
This release represents an ABI change and the DLL version naming has
incremented from 1 to 2, e.g. pthreadVC2.dll.
Version 1.4.0 back-ports the new functionality included in this
release. Please distribute DLLs built from that version with updates
to applications built on pthreads-win32 version 1.x.x.
The package naming has changed, replacing the snapshot date with
the version number + descriptive information. E.g. this
release is "pthreads-w32-2-0-0-release".
Bugs fixed
----------
* pthread_setcancelstate() no longer checks for a pending
async cancel event if the library is using alertable async
cancel. See the README file (Prerequisites section) for info
on adding alertable async cancelation.
New features
------------
* pthread_once() now supports init_routine cancellability.
New tests
---------
* Agressively test pthread_once() init_routine cancellability.
SNAPSHOT 2005-03-08
-------------------
Version 1.3.0
Bug reports (fixed)
-------------------
* Implicitly created threads leave Win32 handles behind after exiting.
- Dmitrii Semii
* pthread_once() starvation problem.
- Gottlob Frege
New tests
---------
* More intense testing of pthread_once().
SNAPSHOT 2005-01-25
-------------------
Version 1.2.0
Bug fixes
---------
* Attempted acquisition of a recursive mutex could cause waiting threads
to not be woken when the mutex was released.
- Ralf Kubis <RKubis at mc.com>
* Various package omissions have been fixed.
SNAPSHOT 2005-01-03
-------------------
Version 1.1.0
Bug fixes
---------
* Unlocking recursive or errorcheck mutexes would sometimes
unexpectedly return an EPERM error (bug introduced in
snapshot-2004-11-03).
- Konstantin Voronkov <beowinkle at yahoo.com>
SNAPSHOT 2004-11-22
-------------------
Version 1.0.0
This snapshot primarily fixes the condvar bug introduced in
snapshot-2004-11-03. DLL versioning has also been included to allow
applications to runtime check the Microsoft compatible DLL version
information, and to extend the DLL naming system for ABI and major
(non-backward compatible) API changes. See the README file for details.
Bug fixes
---------
* Condition variables no longer deadlock (bug introduced in
snapshot-2004-11-03).
- Alexander Kotliarov and Nicolas at saintmac
* DLL naming extended to avoid 'DLL hell' in the future, and to
accommodate the ABI change introduced in snapshot-2004-11-03. Snapshot
2004-11-03 will be removed from FTP sites.
New features
------------
* A Microsoft-style version resource has been added to the DLL for
applications that wish to check DLL compatibility at runtime.
* Pthreads-win32 DLL naming has been extended to allow incompatible DLL
versions to co-exist in the same filesystem. See the README file for details,
but briefly: while the version information inside the DLL will change with
each release from now on, the DLL version names will only change if the new
DLL is not backward compatible with older applications.
The versioning scheme has been borrowed from GNU Libtool, and the DLL
naming scheme is from Cygwin. Provided the Libtool-style numbering rules are
honoured, the Cygwin DLL naming scheme automatcally ensures that DLL name
changes are minimal and that applications will not load an incompatible
pthreads-win32 DLL.
Those who use the pre-built DLLs will find that the DLL/LIB names have a new
suffix (1) in this snapshot. E.g. pthreadVC1.dll etc.
* The POSIX thread ID reuse uniqueness feature introduced in the last snapshot
has been kept as default, but the behaviour can now be controlled when the DLL
is built to effectively switch it off. This makes the library much more
sensitive to applications that assume that POSIX thread IDs are unique, i.e.
are not strictly compliant with POSIX. See the PTW32_THREAD_ID_REUSE_INCREMENT
macro comments in config.h for details.
Other changes
-------------
Certain POSIX macros have changed.
These changes are intended to conform to the Single Unix Specification version 3,
which states that, if set to 0 (zero) or not defined, then applications may use
sysconf() to determine their values at runtime. Pthreads-win32 does not
implement sysconf().
The following macros are no longer undefined, but defined and set to -1
(not implemented):
_POSIX_THREAD_ATTR_STACKADDR
_POSIX_THREAD_PRIO_INHERIT
_POSIX_THREAD_PRIO_PROTECT
_POSIX_THREAD_PROCESS_SHARED
The following macros are defined and set to 200112L (implemented):
_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
The following macros are defined and set to appropriate values:
_POSIX_THREAD_THREADS_MAX
_POSIX_SEM_VALUE_MAX
_POSIX_SEM_NSEMS_MAX
PTHREAD_DESTRUCTOR_ITERATIONS
PTHREAD_KEYS_MAX
PTHREAD_STACK_MIN
PTHREAD_THREADS_MAX
SNAPSHOT 2004-11-03
-------------------
DLLs produced from this snapshot cannot be used with older applications without
recompiling the application, due to a change to pthread_t to provide unique POSIX
thread IDs.
Although this snapshot passes the extended test suite, many of the changes are
fairly major, and some applications may show different behaviour than previously,
so adopt with care. Hopefully, any changed behaviour will be due to the library
being better at it's job, not worse.
Bug fixes
---------
* pthread_create() no longer accepts NULL as the thread reference arg.
A segfault (memory access fault) will result, and no thread will be
created.
* pthread_barrier_wait() no longer acts as a cancelation point.
* Fix potential race condition in pthread_once()
- Tristan Savatier <tristan at mpegtv.com>
* Changes to pthread_cond_destroy() exposed some coding weaknesses in several
test suite mini-apps because pthread_cond_destroy() now returns EBUSY if the CV
is still in use.
New features
------------
* Added for compatibility:
PTHREAD_RECURSIVE_MUTEX_INITIALIZER,
PTHREAD_ERRORCHECK_MUTEX_INITIALIZER,
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP,
PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP
* Initial support for Digital Mars compiler
- Anuj Goyal <anuj.goyal at gmail.com>
* Faster Mutexes. These have been been rewritten following a model provided by
Alexander Terekhov that reduces kernel space checks, and eliminates some additional
critical sections used to manage a race between timedlock expiration and unlock.
Please be aware that the new mutexes do not enforce strict absolute FIFO scheduling
of mutexes, however any out-of-order lock acquisition should be very rare.
* Faster semaphores. Following a similar model to mutexes above, these have been
rewritten to use preliminary users space checks.
* sem_getvalue() now returns the number of waiters.
* The POSIX thread ID now has much stronger uniqueness characteristics. The library
garrantees not to reuse the same thread ID for at least 2^(wordsize) thread
destruction/creation cycles.
New tests
---------
* semaphore4.c: Tests cancelation of the new sem_wait().
* semaphore4t.c: Likewise for sem_timedwait().
* rwlock8.c: Tests and times the slow execution paths of r/w locks, and the CVs,
mutexes, and semaphores that they're built on.
SNAPSHOT 2004-05-16
-------------------
Attempt to add Watcom to the list of compilers that can build the library.
This failed in the end due to it's non-thread-aware errno. The library
builds but the test suite fails. See README.Watcom for more details.
Bug fixes
---------
* Bug and memory leak in sem_init()
- Alex Blanco <Alex.Blanco at motorola.com>
* ptw32_getprocessors() now returns CPU count of 1 for WinCE.
- James Ewing <james.ewing at sveasoft.com>
* pthread_cond_wait() could be canceled at a point where it should not
be cancelable. Fixed.
- Alexander Terekhov <TEREKHOV at de.ibm.com>
* sem_timedwait() had an incorrect timeout calculation.
- Philippe Di Cristo <philipped at voicebox.com>
* Fix a memory leak left behind after threads are destroyed.
- P. van Bruggen <pietvb at newbridges.nl>
New features
------------
* Ported to AMD64.
- Makoto Kato <raven at oldskool.jp>
* True pre-emptive asynchronous cancelation of threads. This is optional
and requires that Panagiotis E. Hadjidoukas's QueueUserAPCEx package be
installed. This package is included in the pthreads-win32 self-unpacking
Zip archive starting from this snapshot. See the README.txt file inside
the package for installation details.
Note: If you don't use async cancelation in your application, or don't need
to cancel threads that are blocked on system resources such as network I/O,
then the default non-preemptive async cancelation is probably good enough.
However, pthreads-win32 auto-detects the availability of these components
at run-time, so you don't need to rebuild the library from source if you
change your mind later.
All of the advice available in books and elsewhere on the undesirability
of using async cancelation in any application still stands, but this
feature is a welcome addition with respect to the library's conformance to
the POSIX standard.
SNAPSHOT 2003-09-18
-------------------
Cleanup of thread priority management. In particular, setting of thread
priority now attempts to map invalid Win32 values within the range returned
by sched_get_priority_min/max() to useful values. See README.NONPORTABLE
under "Thread priority".
Bug fixes
---------
* pthread_getschedparam() now returns the priority given by the most recent
call to pthread_setschedparam() or established by pthread_create(), as
required by the standard. Previously, pthread_getschedparam() incorrectly
returned the running thread priority at the time of the call, which may have
been adjusted or temporarily promoted/demoted.
* sched_get_priority_min() and sched_get_priority_max() now return -1 on error
and set errno. Previously, they incorrectly returned the error value directly.
SNAPSHOT 2003-09-04
-------------------
Bug fixes
---------
* ptw32_cancelableWait() now allows cancelation of waiting implicit POSIX
threads.
New test
--------
* cancel8.c tests cancelation of Win32 threads waiting at a POSIX cancelation
point.
SNAPSHOT 2003-09-03
-------------------
Bug fixes
---------
* pthread_self() would free the newly created implicit POSIX thread handle if
DuplicateHandle failed instead of recycle it (very unlikely).
* pthread_exit() was neither freeing nor recycling the POSIX thread struct
for implicit POSIX threads.
New feature - Cancelation of/by Win32 (non-POSIX) threads
---------------------------------------------------------
Since John Bossom's original implementation, the library has allowed non-POSIX
initialised threads (Win32 threads) to call pthreads-win32 routines and
therefore interact with POSIX threads. This is done by creating an on-the-fly
POSIX thread ID for the Win32 thread that, once created, allows fully
reciprical interaction. This did not extend to thread cancelation (async or
deferred). Now it does.
Any thread can be canceled by any other thread (Win32 or POSIX) if the former
thread's POSIX pthread_t value is known. It's TSD destructors and POSIX
cleanup handlers will be run before the thread exits with an exit code of
PTHREAD_CANCELED (retrieved with GetExitCodeThread()).
This allows a Win32 thread to, for example, call POSIX CV routines in the same way
that POSIX threads would/should, with pthread_cond_wait() cancelability and
cleanup handlers (pthread_cond_wait() is a POSIX cancelation point).
By adding cancelation, Win32 threads should now be able to call all POSIX
threads routines that make sense including semaphores, mutexes, condition
variables, read/write locks, barriers, spinlocks, tsd, cleanup push/pop,
cancelation, pthread_exit, scheduling, etc.
Note that these on-the-fly 'implicit' POSIX thread IDs are initialised as detached
(not joinable) with deferred cancelation type. The POSIX thread ID will be created
automatically by any POSIX routines that need a POSIX handle (unless the routine
needs a pthread_t as a parameter of course). A Win32 thread can discover it's own
POSIX thread ID by calling pthread_self(), which will create the handle if
necessary and return the pthread_t value.
New tests
---------
Test the above new feature.
SNAPSHOT 2003-08-19
-------------------
This snapshot fixes some accidental corruption to new test case sources.
There are no changes to the library source code.
SNAPSHOT 2003-08-15
-------------------
Bug fixes
---------
* pthread.dsp now uses correct compile flags (/MD).
- Viv <[email protected]>
* pthread_win32_process_detach_np() fixed memory leak.
- Steven Reddie <[email protected]>
* pthread_mutex_destroy() fixed incorrect return code.
- Nicolas Barry <[email protected]>
* pthread_spin_destroy() fixed memory leak.
- Piet van Bruggen <[email protected]>
* Various changes to tighten arg checking, and to work with later versions of
MinGW32 and MsysDTK.
* pthread_getschedparam() etc, fixed dangerous thread validity checking.
- Nicolas Barry <[email protected]>
* POSIX thread handles are now reused and their memory is not freed on thread exit.
This allows for stronger thread validity checking.
New standard routine
--------------------
* pthread_kill() added to provide thread validity checking to applications.
It does not accept any non zero values for the signal arg.
New test cases
--------------
* New test cases to confirm validity checking, pthread_kill(), and thread reuse.
SNAPSHOT 2003-05-10
-------------------
Bug fixes
---------
* pthread_mutex_trylock() now returns correct error values.
pthread_mutex_destroy() will no longer destroy a recursively locked mutex.
pthread_mutex_lock() is no longer inadvertantly behaving as a cancelation point.
- Thomas Pfaff <[email protected]>
* pthread_mutex_timedlock() no longer occasionally sets incorrect mutex
ownership, causing deadlocks in some applications.
- Robert Strycek <[email protected]> and Alexander Terekhov <[email protected]>
SNAPSHOT 2002-11-04
-------------------
Bug fixes
---------
* sem_getvalue() now returns the correct value under Win NT and WinCE.
- Rob Fanner <[email protected]>
* sem_timedwait() now uses tighter checks for unreasonable
abstime values - that would result in unexpected timeout values.
* ptw32_cond_wait_cleanup() no longer mysteriously consumes
CV signals but may produce more spurious wakeups. It is believed
that the sem_timedwait() call is consuming a CV signal that it
shouldn't.
- Alexander Terekhov <[email protected]>
* Fixed a memory leak in ptw32_threadDestroy() for implicit threads.
* Fixed potential for deadlock in pthread_cond_destroy().
A deadlock could occur for statically declared CVs (PTHREAD_COND_INITIALIZER),
when one thread is attempting to destroy the condition variable while another
is attempting to dynamically initialize it.
- Michael Johnson <[email protected]>
SNAPSHOT 2002-03-02
-------------------
Cleanup code default style. (IMPORTANT)
----------------------------------------------------------------------
Previously, if not defined, the cleanup style was determined automatically
from the compiler/language, and one of the following was defined accordingly:
__CLEANUP_SEH MSVC only
__CLEANUP_CXX C++, including MSVC++, GNU G++
__CLEANUP_C C, including GNU GCC, not MSVC
These defines determine the style of cleanup (see pthread.h) and,
most importantly, the way that cancelation and thread exit (via
pthread_exit) is performed (see the routine ptw32_throw() in private.c).
In short, the exceptions versions of the library throw an exception
when a thread is canceled or exits (via pthread_exit()), which is
caught by a handler in the thread startup routine, so that the
the correct stack unwinding occurs regardless of where the thread
is when it's canceled or exits via pthread_exit().
In this and future snapshots, unless the build explicitly defines (e.g.
via a compiler option) __CLEANUP_SEH, __CLEANUP_CXX, or __CLEANUP_C, then
the build NOW always defaults to __CLEANUP_C style cleanup. This style
uses setjmp/longjmp in the cancelation and pthread_exit implementations,
and therefore won't do stack unwinding even when linked to applications
that have it (e.g. C++ apps). This is for consistency with most
current commercial Unix POSIX threads implementations. Compaq's TRU64
may be an exception (no pun intended) and possible future trend.
Although it was not clearly documented before, it is still necessary to
build your application using the same __CLEANUP_* define as was
used for the version of the library that you link with, so that the
correct parts of pthread.h are included. That is, the possible
defines require the following library versions:
__CLEANUP_SEH pthreadVSE.dll
__CLEANUP_CXX pthreadVCE.dll or pthreadGCE.dll
__CLEANUP_C pthreadVC.dll or pthreadGC.dll
E.g. regardless of whether your app is C or C++, if you link with
pthreadVC.lib or libpthreadGC.a, then you must define __CLEANUP_C.
THE POINT OF ALL THIS IS: if you have not been defining one of these
explicitly, then the defaults as described at the top of this
section were being used.
THIS NOW CHANGES, as has been explained above, but to try to make this
clearer here's an example:
If you were building your application with MSVC++ i.e. using C++
exceptions and not explicitly defining one of __CLEANUP_*, then
__CLEANUP_C++ was automatically defined for you in pthread.h.
You should have been linking with pthreadVCE.dll, which does
stack unwinding.
If you now build your application as you had before, pthread.h will now
automatically set __CLEANUP_C as the default style, and you will need to
link with pthreadVC.dll. Stack unwinding will now NOT occur when a thread
is canceled, or the thread calls pthread_exit().
Your application will now most likely behave differently to previous
versions, and in non-obvious ways. Most likely is that locally
instantiated objects may not be destroyed or cleaned up after a thread
is canceled.
If you want the same behaviour as before, then you must now define
__CLEANUP_C++ explicitly using a compiler option and link with
pthreadVCE.dll as you did before.
WHY ARE WE MAKING THE DEFAULT STYLE LESS EXCEPTION-FRIENDLY?
Because no commercial Unix POSIX threads implementation allows you to
choose to have stack unwinding. Therefore, providing it in pthread-win32
as a default is dangerous. We still provide the choice but unless
you consciously choose to do otherwise, your pthreads applications will
now run or crash in similar ways irrespective of the threads platform
you use. Or at least this is the hope.
WHY NOT REMOVE THE EXCEPTIONS VERSIONS OF THE LIBRARY ALTOGETHER?
There are a few reasons:
- because there are well respected POSIX threads people who believe
that POSIX threads implementations should be exceptions aware and
do the expected thing in that context. (There are equally respected
people who believe it should not be easily accessible, if it's there
at all, for unconditional conformity to other implementations.)
- because pthreads-win32 is one of the few implementations that has
the choice, perhaps the only freely available one, and so offers
a laboratory to people who may want to explore the effects;
- although the code will always be around somewhere for anyone who
wants it, once it's removed from the current version it will not be
nearly as visible to people who may have a use for it.
Source module splitting
-----------------------
In order to enable smaller image sizes to be generated
for applications that link statically with the library,
most routines have been separated out into individual
source code files.
This is being done in such a way as to be backward compatible.
The old source files are reused to congregate the individual
routine files into larger translation units (via a bunch of
# includes) so that the compiler can still optimise wherever
possible, e.g. through inlining, which can only be done
within the same translation unit.
It is also possible to build the entire library by compiling
the single file named "pthread.c", which just #includes all
the secondary congregation source files. The compiler
may be able to use this to do more inlining of routines.
Although the GNU compiler is able to produce libraries with
the necessary separation (the -ffunction-segments switch),
AFAIK, the MSVC and other compilers don't have this feature.
Finally, since I use makefiles and command-line compilation,
I don't know what havoc this reorganisation may wreak amongst
IDE project file users. You should be able to continue