This is the mail archive of the
pthreads-win32@sourceware.org
mailing list for the pthreas-win32 project.
Re: New pthreads-w32 releases available: versions 2.7.0 and 1.11.0
- From: Ross Johnson <rpj at callisto dot canberra dot edu dot au>
- To: hanzhu <schumi dot han at gmail dot com>
- Cc: James Mansion <james at wgold dot demon dot co dot uk>, Pthreads-Win32 list <pthreads-win32 at sources dot redhat dot com>
- Date: Mon, 05 Jun 2006 01:31:43 +1000
- Subject: Re: New pthreads-w32 releases available: versions 2.7.0 and 1.11.0
- References: <HCEPKPMCAJLDGJIBCLGHOEFEFHAA.james@wgold.demon.co.uk> <448245B5.3000400@gmail.com>
hanzhu wrote:
Sure,
We always observe this project!
_______________________________________________________
Best Regards,
hanzhu
James Mansion дµÀ:
Quiet round here - is this still current?
Announcing two new releases of pthreads-w32:-
pthreads-w32-2-7-0-release
pthreads-w32-1-11-0-release
Not sure why I didn't see the OPs message, however ... there have been a
couple of fairly small changes to the package, but no bug fixes or
changes that would affect existing applications. Nevertheless, it's
probably time for another release.
There has been a portability addition that has been placed into CVS:
From the ChangeLog:
2006-01-25 Prashant Thakre <prashant.thakre at gmail.com>
* pthread_cancel.c: Added _M_IA64 register context support.
An issue that has been raised, but has not resulted in any changes in
the code yet, had to do with pthread_barrier_wait(). The following entry
has been placed in the BUGS file, and a note in the Known Bugs section
of the relevant manual pages (also in CVS):
4. pthread_barrier_wait() can deadlock if the number of potential calling
threads for a particular barrier is greater than the barrier count parameter
given to pthread_barrier_init() for that barrier.
This is due to the very lightweight implementation of pthread-win32
barriers.
To cope with more than "count" possible waiters, barriers must effectively
implement all the same safeguards as condition variables, making them much
"heavier" than at present.
The workaround is to ensure that no more than "count" threads attempt to
wait
at the barrier.
Regards.
Ross