Thoughts on editor disappearing issues
rodda at kde.org
Thu Jun 12 12:31:43 UTC 2008
On Thursday 12 June 2008 18:46:14 David Nolden wrote:
> Am Donnerstag, 12. Juni 2008 03:48:45 schrieb Hamish Rodda:
> > Hi,
> > The problem: if the user closes the document while duchain parsing is
> > occurring, the text editor will be deleted and may be accessed after
> > deletion.
> > At this point, we should probably dump all smart ranges and switch to
> > non- smart range parsing, however the file that was just closed may be
> > modified and not saved to disk, so ideally we just need to throw out that
> > parse session and do it again from disk.
> > Seeing as this covers a large body of code, should we thow an exception
> > in the editor integrator, and catch them outside of the duchain parsing
> > (ie. in the parse job). Then, the parse job can try again from disk.
> > Does that sound like a good solution?
> > Cheers,
> > Hamish.
> This sounds complicated and dangerous. If we throw an exception, we have to
> make everything exception-safe, which would also mean that the kate
> interfaces need to be exception-safe(just consider what happens when the
> duchain or smart-lock isn't unlocked correctly).
> Since the smart-ranges are dumped automatically through the notification
> mechanism, I think we only need to do these steps:
> 1. The editor integrator must notice when a document is deleted, so it
> doesn't try to access it any more and stops trying to create
> smart-ranges(This is the main problem I think, because it's usually where
> the crash happens) 2. In the about 3 places where we actually handle
> smart-ranges directly, we've got to make sure that the smart-lock is held
> as long as we handle direct pointers to them, so they cannot be deleted
> without noticing
I guess so, I'll have to look at the current status - do you store non-smart
cursors with every du* object now? that would make it easier.
> Locking issues between duchain-lock and smart-lock make this whole thing a
> bit problematic though.
iirc that's not so bad, we have a consistent order of locking so we just stick
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KDevelop-devel