jakarta-oro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <...@savarese.org>
Subject Re: Thread-safe ORO
Date Thu, 15 Nov 2001 17:13:57 GMT

>since i needed regex in a multithreaded environment, i modified ORO in a
>quite simple way. The version here is now completely instantiated and
>unsynchronized. Tests in threadalizer and by running in several parallel
>threads look fine. If this could be interesting for the repository, just
>tell me.

First, you should send this email to oro-dev and not to me at oro-dev-owner.
I've been bleeding email from jakarta mailing lists for two weeks because
of the change to nagoya (too many details to get into), so if you've sent
previous emails to oro-dev that required moderation approval, I didn't
get them and apologize.

Second, jakarta-oro's .text.regex package is designed to work correctly
and efficiently with multiple threads (search the archives for a discussion
of why people misunderstand the meaning of thread-safe).  Synchronization
is avoided wherever possible.  You should use a separate matcher and compiler
for each thread (unless you precompile your patterns, in which case you only
need a separate matcher per thread).  If you want to share a pattern
between threads, compile with READ_ONLY_MASK (assuming you're using the
.text.regex package, otherwise no extra flag is needed).  This is
intentional and maximizes opportunities for optimizing performance.  If
you want something "easy to use" but less efficient use Perl5Util.  In any
case, no, if your modifications add synchronization to the .text.regex
package they will not be considered because they violate the design
principles of the package.  However, if you've developed a factory that
makes it easy for people who don't understand they shouldn't be repeatedly
instantiating matchers every time they need them to share a single one
between threads, then, yes, that would be considered.  But the best thing
to do is to post a diff or URL pointing to a diff to oro-dev because it's
the only way to ensure we really understand your suggestion and can discuss
it without rejecting it prematurely.  Even if a suggestion is rejected,
it may lead to a more evolved version through discussion and ultimately
be incorporated.

daniel



--
To unsubscribe, e-mail:   <mailto:oro-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:oro-dev-help@jakarta.apache.org>


Mime
View raw message