This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Sync model for BracesMatcher is too restrictive | ||
|---|---|---|---|
| Product: | editor | Reporter: | Vitezslav Stejskal <vstejskal> |
| Component: | Navigation | Assignee: | issues@editor <issues> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | jjancura, jlahoda, pjiricka |
| Priority: | P2 | Keywords: | API, API_REVIEW_FAST |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | Windows XP | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 143022 | ||
| Attachments: | The changes in editor.bracesmatching | ||
|
Description
Vitezslav Stejskal
2008-03-27 12:56:14 UTC
See issue #131060 for an example, where locking the document causes problems. The new Parser API might provide some guidelines for dealing with situations like this one. This issue causes deadlocks in html editor. Please consider this as defect, not enhancement. This really needs to be fixed in 6.5. Thanks for understanding. *** Issue 137343 has been marked as a duplicate of this issue. *** *** Issue 134046 has been marked as a duplicate of this issue. *** When addressing this issue, please also do not forget about issue 130512 which lists some other problems related to the bracket matching api. I am not sure if there is an issue, but as we discussed earlier with Vita and Tomas Zezula, introduction of a push model for the braces matching would be reasonable solution. I belive Honza Lahoda worked on it, right? Even after partiall fix of the problem - testing Source lock before entering into the deadlocks still happen. I belive we need to address this issue within 6.5. After many offline discussions with mfukala and tzezula I decided to change the infrastructure not to lock the document before calling BracesMatcher implementations. This is a semantic change in the SPI, because BracesMatcher implementations are now obliged to readlock the document if they directly search through its contents. If they use other means of determining matching areas they may not need to lock the document at all. But the decision is up to them. I updated all BracesMatcher implementations in the standard Netbeans distribution to comply with the changed semantics. I'm also going to attach the diff with the API changes. The parts of the diff important for apireview are in BracesMatcher.java (the actual change), CharacterMatcher.java (how it affects a typical existing client) and the obvious apichanges.xml, manifest.mf. Created attachment 68455 [details]
The changes in editor.bracesmatching
I kindly ask for reviewing this change. Thank you I pushed the changes. Thanks http://hg.netbeans.org/main/rev/4f9dc43334c1 fixed |