[00/10] Reduce #ifdef NO_PTHREADS
mbox series

Message ID 20181027071003.1347-1-pclouds@gmail.com
Headers show
Series
  • Reduce #ifdef NO_PTHREADS
Related show

Message

Duy Nguyen Oct. 27, 2018, 7:09 a.m. UTC
People seemed to support the idea of removing these #ifdef NO_PTHREADS [1]
so this is a complete series. I left the #ifdef in run-command.c and
transport-helper.c because those code looked complicated so perhaps we
could clean them up later. Even these updated files could be updated
more, I think, to reduce some code duplication, but I tried to keep
the change here minimal.

[1] https://public-inbox.org/git/20181018180522.17642-1-pclouds@gmail.com/

Nguyễn Thái Ngọc Duy (10):
  thread-utils: macros to unconditionally compile pthreads API
  index-pack: remove #ifdef NO_PTHREADS
  name-hash.c: remove #ifdef NO_PTHREADS
  attr.c: remove #ifdef NO_PTHREADS
  send-pack.c: remove #ifdef NO_PTHREADS
  grep: remove #ifdef NO_PTHREADS
  preload-index.c: remove #ifdef NO_PTHREADS
  pack-objects: remove #ifdef NO_PTHREADS
  read-cache.c: remove #ifdef NO_PTHREADS
  Clean up pthread_create() error handling

 Makefile               |  2 +-
 attr.c                 | 14 ---------
 builtin/grep.c         | 58 +++++++++++++----------------------
 builtin/index-pack.c   | 68 +++++++++++-------------------------------
 builtin/pack-objects.c | 26 ++--------------
 grep.c                 |  6 ----
 grep.h                 |  6 ----
 name-hash.c            | 38 +++++++++--------------
 pack-objects.h         |  6 ----
 preload-index.c        | 23 +++++---------
 read-cache.c           | 49 +++++++++++-------------------
 run-command.c          |  2 +-
 send-pack.c            |  8 ++---
 thread-utils.c         | 48 +++++++++++++++++++++++++++++
 thread-utils.h         | 47 +++++++++++++++++++++++++++--
 15 files changed, 178 insertions(+), 223 deletions(-)

Comments

Jeff King Oct. 27, 2018, 7:24 a.m. UTC | #1
On Sat, Oct 27, 2018 at 09:09:53AM +0200, Nguyễn Thái Ngọc Duy wrote:

> People seemed to support the idea of removing these #ifdef NO_PTHREADS [1]
> so this is a complete series. I left the #ifdef in run-command.c and
> transport-helper.c because those code looked complicated so perhaps we
> could clean them up later. Even these updated files could be updated
> more, I think, to reduce some code duplication, but I tried to keep
> the change here minimal.

Some of the bits in run-command.c can probably be converted, but all of
the "struct async" bits can't ever be. Because there the fallback is not
"OK, let's just run a single thread" but a whole separate forking
mechanism.

-Peff
Jeff King Oct. 27, 2018, 8:13 a.m. UTC | #2
On Sat, Oct 27, 2018 at 09:09:53AM +0200, Nguyễn Thái Ngọc Duy wrote:

> People seemed to support the idea of removing these #ifdef NO_PTHREADS [1]
> so this is a complete series. I left the #ifdef in run-command.c and
> transport-helper.c because those code looked complicated so perhaps we
> could clean them up later. Even these updated files could be updated
> more, I think, to reduce some code duplication, but I tried to keep
> the change here minimal.
> 
> [1] https://public-inbox.org/git/20181018180522.17642-1-pclouds@gmail.com/
> 
> Nguyễn Thái Ngọc Duy (10):
>   thread-utils: macros to unconditionally compile pthreads API
>   index-pack: remove #ifdef NO_PTHREADS
>   name-hash.c: remove #ifdef NO_PTHREADS
>   attr.c: remove #ifdef NO_PTHREADS
>   send-pack.c: remove #ifdef NO_PTHREADS
>   grep: remove #ifdef NO_PTHREADS
>   preload-index.c: remove #ifdef NO_PTHREADS
>   pack-objects: remove #ifdef NO_PTHREADS
>   read-cache.c: remove #ifdef NO_PTHREADS
>   Clean up pthread_create() error handling

Compiling with NO_PTHREADS=1, I get (with gcc 8.2.0):

read-cache.c: In function ‘do_read_index’:
read-cache.c:1820:4: error: ‘copy_len’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
    memcpy(ce->name, previous_ce->name, copy_len);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
read-cache.c:1749:9: note: ‘copy_len’ was declared here
  size_t copy_len;

which seems wrong to me. It's always tied to expand_name_field being
true. And curiously an earlier use doesn't trigger the warning. I wonder
if some kind of tricky pointer aliasing in the intervening code makes it
think that expand_name_field could change, but I sure don't see it.

I ran the tests under ASan/UBSan, since this series seems like it has a
good chance of accidentally causing issues there, but didn't come up
with any problems (except for the ones already fixed on pu by 8628ace269
(commit-reach: fix cast in compare_commits_by_gen(), 2018-10-01)).

-Peff
Duy Nguyen Oct. 27, 2018, 5:07 p.m. UTC | #3
On Sat, Oct 27, 2018 at 10:13 AM Jeff King <peff@peff.net> wrote:
>
> On Sat, Oct 27, 2018 at 09:09:53AM +0200, Nguyễn Thái Ngọc Duy wrote:
>
> > People seemed to support the idea of removing these #ifdef NO_PTHREADS [1]
> > so this is a complete series. I left the #ifdef in run-command.c and
> > transport-helper.c because those code looked complicated so perhaps we
> > could clean them up later. Even these updated files could be updated
> > more, I think, to reduce some code duplication, but I tried to keep
> > the change here minimal.
> >
> > [1] https://public-inbox.org/git/20181018180522.17642-1-pclouds@gmail.com/
> >
> > Nguyễn Thái Ngọc Duy (10):
> >   thread-utils: macros to unconditionally compile pthreads API
> >   index-pack: remove #ifdef NO_PTHREADS
> >   name-hash.c: remove #ifdef NO_PTHREADS
> >   attr.c: remove #ifdef NO_PTHREADS
> >   send-pack.c: remove #ifdef NO_PTHREADS
> >   grep: remove #ifdef NO_PTHREADS
> >   preload-index.c: remove #ifdef NO_PTHREADS
> >   pack-objects: remove #ifdef NO_PTHREADS
> >   read-cache.c: remove #ifdef NO_PTHREADS
> >   Clean up pthread_create() error handling
>
> Compiling with NO_PTHREADS=1, I get (with gcc 8.2.0):
>
> read-cache.c: In function ‘do_read_index’:
> read-cache.c:1820:4: error: ‘copy_len’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>     memcpy(ce->name, previous_ce->name, copy_len);
>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> read-cache.c:1749:9: note: ‘copy_len’ was declared here
>   size_t copy_len;
>
> which seems wrong to me. It's always tied to expand_name_field being
> true. And curiously an earlier use doesn't trigger the warning. I wonder
> if some kind of tricky pointer aliasing in the intervening code makes it
> think that expand_name_field could change, but I sure don't see it.

I couldn't reproduce it with gcc 8.2.0 on gentoo (I tried all
optimization levels just in case). I agree the warning is wrong. But I
will initialize copy_len anyway to avoid this.