can we deprecate NO_PTHREADS?, was: better wrapper to avoid #ifdef NO_PTHREADS

[Jeff King <peff@peff.net>]

On Fri, Oct 26, 2018 at 10:09:46AM -0400, Ben Peart wrote:

> > Yeah, I don't think carrying around a handful of ints is going to be a
> > big deal.
> 
> Just to be complete, there _is_ an additional cost.  Today, code paths that
> are only executed when there are pthreads available are excluded from the
> binary (via #ifdef).  With this change, those code paths would now be
> included causing some code bloat to NO_PTHREAD threaded images.
> 
> One example of this is in read-cache.c where the ieot read/write functions
> aren't included for NO_PTHREAD but now would be.

Yeah. I think that is also an OK cost. It may bloat the binary a little,
but if we're not running those instructions, they're probably not
bloating CPU cache, etc.

> > I don't think we should break the build on those legacy systems, but
> > it's probably OK to stop thinking of it as "non-threaded platforms are
> > the default and must pay zero cost" and more as "threaded platforms are
> > the default, and non-threaded ones are OK to pay a small cost as long as
> > they still work".
> 
> I agree though I'm still curious if there are still no-threaded platforms
> taking new versions of git.  Perhaps we should do the depreciation warning
> you suggested elsewhere and see how much push back we get.  It's unlikely
> we'd get lucky and be able to stop supporting them completely but it's worth
> asking!

I'm trying to think how that might look. I think putting it into the
binary and warning at runtime is probably a little _too_ obnoxious. Here
are some other options ranging from less to more annoying:

  - mention it in the release notes (guaranteed not to hurt anybody, but
    also likely to be missed)

  - a build-time warning when the NO_PTHREADS is set. Also easy to miss,
    but at least hits the people who are using it.

  - rename NO_PTHREADS to NO_PTHREADS_REALLY, and error out the build
    when NO_PTHREADS is set. That would certainly get people's
    attention.

I guess it would make sense to do them in ascending order. I.e., maybe
start with something like:

diff --git a/Makefile b/Makefile
index b08d5ea258..8ac234e4c3 100644
--- a/Makefile
+++ b/Makefile
@@ -1670,6 +1670,11 @@ ifdef RUNTIME_PREFIX
 endif
 
 ifdef NO_PTHREADS
+$(warning The NO_PTHREADS flag is being considered for deprecation,)
+$(warning which would require all platforms supported by Git to have)
+$(warning some kind of threading support. If your platform does not)
+$(warning support threading, please report it by sending an email to)
+$(warning git@vger.kernel.org.)
 	BASIC_CFLAGS += -DNO_PTHREADS
 else
 	BASIC_CFLAGS += $(PTHREAD_CFLAGS)

If we get no takers, that doesn't prove much, but it builds confidence
in moving to the "REALLY" variant. And if we do get a report, we can be
told this is a bad idea before moving further.

Also, the posting of the patch itself may gather some feedback. ;)

-Peff