Thoughts on editor disappearing issues

[Hamish Rodda]

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).

ok

> 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 
to that.

Cheers,
Hamish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080612/ed737a20/attachment.html>