emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#24259: closed ([PATCH 0/6] dfa: thread safety)


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#24259: closed ([PATCH 0/6] dfa: thread safety)
Date: Sun, 21 Aug 2016 00:53:01 +0000

Your message dated Sat, 20 Aug 2016 17:52:09 -0700
with message-id <address@hidden>
and subject line Re: bug#24259: [PATCH 0/6] dfa: thread safety
has caused the debbugs.gnu.org bug report #24259,
regarding [PATCH 0/6] dfa: thread safety
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
24259: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24259
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [PATCH 0/6] dfa: thread safety Date: Thu, 18 Aug 2016 05:50:13 -0500
Hello,

Re: Jim Meyering's proposal to move grep's dfa.c into gnulib, I was
hoping I might be able to sneak in the dfa-related parts of my
multithreading patch set before it happens.

These are all the patches from that set that touch src/dfa.[ch], and
are all oriented toward making dfa.c thread-safe (which seems like it
might be a desirable thing for librarification anyway).  Starting with
the fourth patch there are some slight changes to the external API, so
other projects using dfa.c may need some minor corresponding
adjustments as a result (but nothing, I think, too onerous).  The
first three should have no impact on any users, however.

(The bulk of the changes in these patches are fairly mechanical; for
some of them something like `git show --color-words' on a local branch
might make the review process slightly less tedious.)

Combined diffstat for these six follows.

Thanks,
Zev Weiss

 src/dfa.c             | 854 ++++++++++++++++++++++--------------------
 src/dfa.h             |  13 +-
 src/dfasearch.c       |   7 +-
 src/grep.c            |   2 +
 src/kwsearch.c        |   2 +-
 src/pcresearch.c      |   2 +-
 tests/dfa-match-aux.c |   4 +-
 7 files changed, 470 insertions(+), 414 deletions(-)




--- End Message ---
--- Begin Message --- Subject: Re: bug#24259: [PATCH 0/6] dfa: thread safety Date: Sat, 20 Aug 2016 17:52:09 -0700
On Thu, Aug 18, 2016 at 3:50 AM, Zev Weiss <address@hidden> wrote:
> Hello,
>
> Re: Jim Meyering's proposal to move grep's dfa.c into gnulib, I was
> hoping I might be able to sneak in the dfa-related parts of my
> multithreading patch set before it happens.
>
> These are all the patches from that set that touch src/dfa.[ch], and
> are all oriented toward making dfa.c thread-safe (which seems like it
> might be a desirable thing for librarification anyway).  Starting with
> the fourth patch there are some slight changes to the external API, so
> other projects using dfa.c may need some minor corresponding
> adjustments as a result (but nothing, I think, too onerous).  The
> first three should have no impact on any users, however.
>
> (The bulk of the changes in these patches are fairly mechanical; for
> some of them something like `git show --color-words' on a local branch
> might make the review process slightly less tedious.)
>
> Combined diffstat for these six follows.
>
> Thanks,
> Zev Weiss
>
>  src/dfa.c             | 854 ++++++++++++++++++++++--------------------
>  src/dfa.h             |  13 +-
>  src/dfasearch.c       |   7 +-
>  src/grep.c            |   2 +
>  src/kwsearch.c        |   2 +-
>  src/pcresearch.c      |   2 +-
>  tests/dfa-match-aux.c |   4 +-

Thank you for separating those so nicely.
I have pushed your patches 2..6, now, so will close this.
The only changes I made were to the formatting and member ordering of
struct lexer_state. At first glance, I thought reordering would save
some space, but ended up with a size of 56 bytes on x86_64 regardless.
However, I did move both "int cur_mb_len" and "bool laststart" to the
end, and note that changing the type of cur_mb_len to short int
(perhaps in a later patch) will reduce the size of that struct to 48.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]