New snapshot 2004-05-16 available

New snapshot 2004-05-16 available

[Ross Johnson]

Dear all,

Finally there is a new snapshot available that incorporates 99 percent 
of the issues raised over the past 8 to 9 months, including some that 
had not made it into CVS until today.

http://source.redhat.com/pthreads-win32
and
ftp://sources.redhat.com/pub/pthreads-win32


Here are the main changes:

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.

Note: This is probably a result of not defining the appropriate macro.

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. Many thanks to Panagiotis for his
assistance in getting the hooks into the library.

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.

Re: New snapshot 2004-05-16 available

[Ross Johnson]

Thanks for the quick feedback.

ptw32_semwait.c is now in CVS (it is already in the self-extracting zip 
file on the FTP site but not yet in the tar.gz packages).

Also, the version of implement.h in CVS now #defines _WIN32_WINNT 0x400, 
which should give PAPCFUNC meaning. The makefiles that I use are too 
helpful - they define _WIN32_WINNT on the CL command line.

Ross

cameni@manabove.org wrote:

>We are having problems compiling source from cvs:
>
>- seems that ptw32_semwait.c was not added to the cvs
>- PAPCFUNC isn't declared when _WIN32_WINNT isn't declared implement.h:449
>- in pthreads_cancel.c:179, the thread->cancelLock isn't unlocked when
>WaitForSingleObject returns anything else than WAIT_TIMEOUT (if it terminates
>earlier during pthread_cancel)
>
>brk
>
>
>Ross Johnson wrote:
>  
>
>>Dear all,
>>
>>Finally there is a new snapshot available that incorporates 99 percent 
>>of the issues raised over the past 8 to 9 months, including some that 
>>had not made it into CVS until today.
>>
>>http://source.redhat.com/pthreads-win32
>>and
>>ftp://sources.redhat.com/pub/pthreads-win32
>>
>>
>>Here are the main changes:
>>
>>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.
>>
>>Note: This is probably a result of not defining the appropriate macro.
>>
>>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. Many thanks to Panagiotis for his
>>assistance in getting the hooks into the library.
>>
>>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.
>>
>>
>>    
>>
>
>  
>

Re: New snapshot 2004-05-16 available

[Dr. Michael Heitland (caatoosee ag)]

Hello,

I have the same problems while building pthreads with VC71.

Furthermore, I get a syntax error in implement.h
    DWORD

    ptw32_RegisterCancelation (PAPCFUNC callback,

It seems that windows.h is not properly included.

Greetings,

Michael Heitland

----- Original Message ----- 
From: <cameni@manabove.org>
To: <pthreads-win32@sources.redhat.com>
Sent: Monday, May 17, 2004 9:37 AM
Subject: Re: New snapshot 2004-05-16 available


> We are having problems compiling source from cvs:
>
> - seems that ptw32_semwait.c was not added to the cvs
> - PAPCFUNC isn't declared when _WIN32_WINNT isn't declared implement.h:449
> - in pthreads_cancel.c:179, the thread->cancelLock isn't unlocked when
> WaitForSingleObject returns anything else than WAIT_TIMEOUT (if it
terminates
> earlier during pthread_cancel)
>
> brk
>
>
> Ross Johnson wrote:
> > Dear all,
> >
> > Finally there is a new snapshot available that incorporates 99 percent
> > of the issues raised over the past 8 to 9 months, including some that
> > had not made it into CVS until today.
> >
> > http://source.redhat.com/pthreads-win32
> > and
> > ftp://sources.redhat.com/pub/pthreads-win32
> >
> >
> > Here are the main changes:
> >
> > 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.
> >
> > Note: This is probably a result of not defining the appropriate macro.
> >
> > 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. Many thanks to Panagiotis for his
> > assistance in getting the hooks into the library.
> >
> > 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.
> >
> >
>

Re: New snapshot 2004-05-16 available

[cameni]

We are having problems compiling source from cvs:

- seems that ptw32_semwait.c was not added to the cvs
- PAPCFUNC isn't declared when _WIN32_WINNT isn't declared implement.h:449
- in pthreads_cancel.c:179, the thread->cancelLock isn't unlocked when
WaitForSingleObject returns anything else than WAIT_TIMEOUT (if it terminates
earlier during pthread_cancel)

brk


Ross Johnson wrote:
> Dear all,
> 
> Finally there is a new snapshot available that incorporates 99 percent 
> of the issues raised over the past 8 to 9 months, including some that 
> had not made it into CVS until today.
> 
> http://source.redhat.com/pthreads-win32
> and
> ftp://sources.redhat.com/pub/pthreads-win32
> 
> 
> Here are the main changes:
> 
> 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.
> 
> Note: This is probably a result of not defining the appropriate macro.
> 
> 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. Many thanks to Panagiotis for his
> assistance in getting the hooks into the library.
> 
> 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.
> 
>