This is the mail archive of the
mailing list for the Cygwin project.
RE: [PATCH] added locks in pthread code
- From: "Robert Collins" <robert dot collins at syncretize dot net>
- To: "'Robert Collins'" <robert dot collins at syncretize dot net>,"'Thomas Pfaff'" <tpfaff at gmx dot net>
- Cc: <cygwin-patches at cygwin dot com>
- Date: Mon, 10 Jun 2002 18:46:29 +1000
- Subject: RE: [PATCH] added locks in pthread code
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Robert Collins
> Sent: Monday, 10 June 2002 6:41 PM
> To: 'Thomas Pfaff'
> Cc: firstname.lastname@example.org
> Subject: RE: [PATCH] added locks in pthread code
> > -----Original Message-----
> > From: Thomas Pfaff [mailto:email@example.com]
> > Sent: Monday, 10 June 2002 4:48 PM
> > To: Robert Collins
> > Cc: firstname.lastname@example.org
> > Subject: RE: [PATCH] added locks in pthread code
> > I wanted to make sure that a thread can not be cancelled
> > asynchronous when
> > it is in the cleanup push call, but i think it could be done
> > better with
> > InterlockedExchangePointer.
> Yes. Look at the destructor code, or the pthread_atfork list code -
> there is a thread safe list based around InterlockedExchangePointer.
Or, call setcancelstate twice during your pthread_cleanup_push macro.
Once to set PTHREAD_CANCEL_ENABLE, and once to restore the old value.
That avoids the issue completely, and is in spec with P1003.1.