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: | Deadlock on Source vs. CloneableOpenSupport$Listener in EventSupport$DocListener.propertyChange | ||
|---|---|---|---|
| Product: | editor | Reporter: | Jesse Glick <jglick> |
| Component: | Parsing & Indexing | Assignee: | issues@editor <issues> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | issues, mslama, phejl |
| Priority: | P3 | Keywords: | THREAD |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
|
Description
Jesse Glick
2009-01-07 20:27:23 UTC
> 090105; IDE froze opening a source file. Bug seems to be in EventSupport$DocListener.propertyChange - you are not
> permitted to acquire a lock in a listener callback.
Well, I thought that listener callbacks are not supposed to be called when the caller holds a lock. I don't see anything
in javadoc for EditorCookie.Observable.add{remove}PCL saying that added listeners will be called when an internal lock
in CloneableEditorSupport is held.
I know CES contains complex code for loading documents and maybe there is a good reason for doing things the way how
they are done now. But it definitely is not a common practice and should be mentioned in javadoc.
*** Issue 156461 has been marked as a duplicate of this issue. *** *** Issue 156340 has been marked as a duplicate of this issue. *** I am just moving firing change document event out of CES internal lock. This should fix this issue. See issue #155326. Thanks a lot Marku. I'll leave this open until we are sure that your change fixed the problem. "listener callbacks are not supposed to be called when the caller holds a lock" - unfortunately this is not avoidable in general, assuming you want to fire events synchronously, which is generally desirable (makes behavior more predictable and testable). "I don't see anything in Javadoc for [...].addPCL saying that added listeners will be called when an internal lock [...] is held" - the onus is not on the event source. The onus is on listeners to not acquire their own locks. This is a general fact for any listener so it need not be specifically mentioned in Javadoc. > The onus is on listeners to not acquire their own locks. This is a general fact for any listener so it need not
> be specifically mentioned in Javadoc.
Are you sure Jesse? This is in contrast with how I believe we have been approaching these problems in Netbeans so far.
Anyway, Marek changed CloneableOpenSupport not to call listeners when holding the lock, which I think fixed this problem.
"this is in contrast with how I believe we have been approaching these problems in NetBeans so far" - I can't track every deadlock reported & solved in NB, but my general advice is that a listener should never acquire a lock or perform other potentially blocking actions. There are many cases where listeners must be notified and calling code is holding a lock, where moving the notification out of the lock would not be practical. Yes it is not always possible to move event firing out of lock especially when code spans over multiple modules. Example is issue #155680 where call of DataEditorSupport.Env.getTime() -> FileObject.refresh can cause fileChange event from fs. But I cannot call getTime() later so I had to workaround this by another way. In this case this fileChange event can be ignore. It is just to show that it is not always possible to move event firing out of lock. *** Issue 156995 has been marked as a duplicate of this issue. *** This seems to be really fixed. Thanks Marku. |