[Top][All Lists]

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

Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; up

From: Daniel Colascione
Subject: Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
Date: Sun, 17 Jun 2018 12:18:13 -0700
User-agent: SquirrelMail/1.4.23 [SVN]

>>>     (unfreeze_pattern, freeze_pattern): New functions.
>>>     (compile_pattern): Return a regexp_cache pointer instead of the
>>>     re_pattern_buffer, allowing callers to use `freeze_pattern' if
>>>     needed.  Do not consider busy patterns as cache hit candidates;
>>>     error if we run out of non-busy cache entries.
>> IIRC the main/only reason why you can't use a compiled pattern in
>> a reentrant way is because the \{N,M\} repetitions use a counter that's
>> stored directly within the compiled pattern.
>> But these are fairly rare.
>> So we could easily change the code to add a boolean stating whether
>> there
>> is such a repetition-counter in the pattern, and if there isn't then
>> "freeze" can just do nothing because we can freely use that pattern
>> multiple times at the same time.
> Good idea. My reading of the "smart jump" stuff in regex.c suggested that
> we use the optimization for _all_ greedy Kleene star constructs though,
> not just the bounded ones. Am I wrong?

Oh, yeah. One more thing. The busy flag isn't *just* to prevent the regex
bytecode engine confusing itself with self-modifying bytecode. It also
serves to protect the cache slot holding the regex pattern from reuse,
which would be disastrous whether or not the bytecode of a particular
pattern happens to be mutable. Under your proposal, we can get cache hits
on busy patterns, but we still have to mark them busy in the first place
so we can prevent this reuse.

reply via email to

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