From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25786 invoked by alias); 4 Jun 2006 15:32:00 -0000 Received: (qmail 25778 invoked by uid 22791); 4 Jun 2006 15:32:00 -0000 X-Spam-Check-By: sourceware.org Received: from quokka.dot.net.au (HELO quokka.dot.net.au) (202.147.68.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 04 Jun 2006 15:31:56 +0000 Received: from [203.129.38.35] (helo=[203.129.38.35]) by quokka.dot.net.au with esmtp (Exim 3.35 #1 (Debian)) id 1FmuZu-0007Yq-00; Mon, 05 Jun 2006 01:31:47 +1000 Message-ID: <4482FCDF.8010900@callisto.canberra.edu.au> Date: Sun, 04 Jun 2006 15:32:00 -0000 From: Ross Johnson User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) MIME-Version: 1.0 To: hanzhu CC: James Mansion , Pthreads-Win32 list Subject: Re: New pthreads-w32 releases available: versions 2.7.0 and 1.11.0 References: <448245B5.3000400@gmail.com> In-Reply-To: <448245B5.3000400@gmail.com> Content-Type: text/plain; charset=gb18030; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2006/txt/msg00029.txt.bz2 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 * 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