jakarta-oro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Remme" <mre...@braintags.de>
Subject RE: Thread-safe ORO
Date Fri, 16 Nov 2001 12:21:35 GMT
Oops, i'm sorry, Daniel, for sending the mail directly to you, this wasn't
my intention. I just put down in the mailing-list and by accident used a
wrong email-adress from the welcome-message. Sorry again.

Of course, before starting to make my modifications, i searched the archive
and i found and read your message. When i looked into the code, i saw, that
every call to substitute, for instance, is sent to the static
Util.substitute and from there to some other, partially synchronized
methods. And there i don't see a synchonization problem, but a possible
block for threads, which are working parallel with larg textfiles to

Best, Michael

> >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>

Virengepr├╝ft vom G DATA AntiVirenKit

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

View raw message