[ jEdit-devel ] [ jedit-Bugs-1861282 ] Deadlock on startup

[SourceForge.net <no...@so...>]

Bugs item #1861282, was opened at 2007-12-31 11:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1861282&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: severe bug
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deadlock on startup

Initial Comment:
With the jEdit trunk version, and the released version of ProjectViewer (2.9.0.0), jEdit frequently fails to start. I debugged it to find out the following flow that causes the deadlock:
1. During startup, jEdit loads the view configuration from perspective.xml, and tries to open the buffers that are specified there. Loading the buffers is done in the background, in a work thread.
2. As part of loading the perspective.xml file, jEdit tries to restore the dockable windows that were open the last time, one of them was the ProjectViewer dockable.
3. As part of the initialization of the ProjectViewer dockable, it tries to set the root node of the project tree to the last-open project. I configured ProjectViewer to automatically close & open buffers as needed when switching projects, so setting the root node of the project tree attempts to close those buffers that are loaded in the background (that were listed in perpsective.xml as "auto load"). It does that by calling "jEdit.closeBuffer(...)".
4. jEdit.closeBuffer(...) finds that the buffer is still performing an I/O request (being loaded in the background), and invokes "VFSManager.waitForRequests()". This call never returns.

I don't know the exact cause of all this, but I suspect that the jEdit.closeBuffer(...) is called from PV in the AWT thread, and I guess that the notification that the buffer is done loading is also registered to run in the AWT thread, so closeBuffer(...) blocks the AWT thread and prevents the notification to which it is waiting to actually take place.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1861282&group_id=588