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 substitute. 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:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > Virengepr�ft vom G DATA AntiVirenKit -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
