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.

Bug 131284 - Sync model for BracesMatcher is too restrictive
Summary: Sync model for BracesMatcher is too restrictive
Status: RESOLVED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: Navigation (show other bugs)
Version: 6.x
Hardware: All Windows XP
: P2 blocker (vote)
Assignee: issues@editor
URL:
Keywords: API, API_REVIEW_FAST
: 134046 137343 (view as bug list)
Depends on:
Blocks: 143022
  Show dependency tree
 
Reported: 2008-03-27 12:56 UTC by Vitezslav Stejskal
Modified: 2008-08-29 13:13 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
The changes in editor.bracesmatching (14.83 KB, text/plain)
2008-08-27 16:00 UTC, Vitezslav Stejskal 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vitezslav Stejskal 2008-03-27 12:56:14 UTC 
The infrastructure for braces matching now calls provided BracesMatcher implementations under the document's lock (ie.
using Document.render()). This may be too restrictive from some implementations. For example when using parser data from
GSF or Java infrastructure.
Comment 1 Vitezslav Stejskal 2008-03-27 12:57:21 UTC 
See issue #131060 for an example, where locking the document causes problems.
Comment 2 Vitezslav Stejskal 2008-03-27 12:58:54 UTC 
The new Parser API might provide some guidelines for dealing with situations like this one.
Comment 3 Marek Fukala 2008-06-18 08:47:34 UTC 
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.
Comment 4 Marek Fukala 2008-06-18 08:48:51 UTC 
*** Issue 137343 has been marked as a duplicate of this issue. ***
Comment 5 Marek Fukala 2008-06-18 08:51:16 UTC 
*** Issue 134046 has been marked as a duplicate of this issue. ***
Comment 6 Marek Fukala 2008-06-18 08:54:24 UTC 
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?
Comment 7 Marek Fukala 2008-08-06 10:35:16 UTC 
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.
Comment 8 Vitezslav Stejskal 2008-08-27 15:59:16 UTC 
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.
Comment 9 Vitezslav Stejskal 2008-08-27 16:00:24 UTC 
Created attachment 68455 [details]
The changes in editor.bracesmatching
Comment 10 Vitezslav Stejskal 2008-08-27 16:09:11 UTC 
I kindly ask for reviewing this change. Thank you
Comment 11 Vitezslav Stejskal 2008-08-29 13:13:21 UTC 
I pushed the changes. Thanks
http://hg.netbeans.org/main/rev/4f9dc43334c1
Comment 12 Vitezslav Stejskal 2008-08-29 13:13:55 UTC 
fixed