[petsc-dev] PETSc 3.5.0 compilation on Windows and OpenMP with pthread

[Dave Nystrom]

Thanks Barry.  I was just concerned from the comments on this thread that the
current thread support was going to be removed before there was something
better to replace it.

Dave

Barry Smith writes:
 > Dave,
 > 
 > People are free to use the threads and GPU code in PETSc we just do not
 > want people to use it from the release tar balls, we only want them to use
 > it from the repository (either master, next, or some branch). The reason
 > is that we are constantly fixing things related to these and we cannot be
 > putting these constant fixes into the release tar balls.
 > 
 > Barry
 > 
 > On Jul 3, 2014, at 11:47 AM, Dave Nystrom <Dave.Nystrom at tachyonlogic.com> wrote:
 > 
 > > So what exactly do you mean when you say to turn off the support for the
 > > current pthreads support because I have been using it, such as it is, in
 > > the next branch?
 > > 
 > >> -------- Original Message --------
 > >> Subject: Re: [petsc-dev] PETSc 3.5.0 compilation on Windows and OpenMP
 > >> with pthread
 > >> From: Barry Smith <bsmith at mcs.anl.gov>
 > >> Date: Thu, July 03, 2014 10:08 am
 > >> To: Jed Brown <jed at jedbrown.org>
 > >> Cc: "petsc-dev at mcs.anl.gov" <petsc-dev at mcs.anl.gov>
 > >> 
 > >> 
 > >> On Jul 3, 2014, at 8:37 AM, Jed Brown <jed at jedbrown.org> wrote:
 > >> 
 > >>> Satish Balay <balay at mcs.anl.gov> writes:
 > >>>> threadcomm.py is disabled in petsc3.4, 3.5. Should pthreadclasses.py also be
 > >>>> disabled? [should openmp.py also be disabled?]
 > >>>> 
 > >>>> https://bitbucket.org/petsc/petsc/commits/6e5884b57154c4018286842049a07306848380f9#chg-config/PETSc/packages/threadcomm.py
 > >>> 
 > >>> Yes, they can't do anything but cause confusion right now, and the
 > >>> legacy "pthreadclasses" option should go away.
 > >> 
 > >>   Yes turn them all off.
 >