Re: thread-safe regex

["Daniel F. Savarese" <df...@savarese.org>]

In message <00...@blazesoft.com>, "Gabrio Verratti" wr
ites:
>are the substitute and split methods of Util thread-safe?
>what about in version 1.1.0a?

All methods in Util are static and stateless.  Everyone has a different
notion of what they expect from somethings that is thread-safe, so I can't
address that directly.  So long as you compile your Perl5 expressions with
Perl5Compiler.READ_ONLY_MASK when sharing patterns between threads and do
not concurrently use the same matcher in Util.substitute or split you will
not create any undefined behavior.

>given that the Matcher produces a MatchResult as a side-effect, I would
>imagine that you'd want at least one Matcher per thread in a multi-threaded
>context?

Yes, using one matcher per thread is the recommended approach to avoid the
overhead of synchronization.  My reference to constantly reinstantiating
compiler and matcher objects is a specific instance of a more general
pitfall many Java programmers succumb to.  There's this perception that
because Java is garbage collected, you can create objects willy nilly at
no cost.  Many a Java program crawls not because of Java per se, but because
of lack of object (instance) reuse.  For example, you can create a new
Perl5Matcher and Perl5Compiler every time you call a method, but if you're
going to call that method repeatedly, it will be a lot more efficient to make
the matcher and compiler member variables and instantiate them only once.
Better yet, precompile the patterns if you are going to be using the same
ones over and over, or use a PatternCache to manage that for you.

daniel