Regarding commit b9014d21caea4d8fe98c94c1fe6158b65db5db53 by Milian (use IDocument for mimetype query when available)

[Milian Wolff]

David Nolden, 10.06.2011:
> commit b9014d21caea4d8fe98c94c1fe6158b65db5db53
> Author: Milian Wolff <mail at milianw.de>
> Date:   Fri Jun 10 15:09:11 2011 +0200
> 
>     use IDocument for mimetype query when available in language controller
> 
>     this way we get proper language support when opening files without
> extension like e.g. <memory> or similar system headers. Furthermore there
> are scripting
>     languages that use the shebang instead of the extension to
> advertise their mimetype
> 
> 
> The idea is good, but it is not thread-safe to call documentForUrl,
> while languageForUrl can be called from any thread. This patch can
> thus lead to random crashes I think..

You are right, there is a *very* slim chance of a race when the doc is 
returned, then deleted in UI-thread, and we then try to get the mimetype. 
That's what you think, or?

Anyhow, we could still check the same stuff as further below, i.e. compare 
current thread to qapp's thread.

> A better solution would be: When opening a document, force the
> language-controller to cache its type, or something like that.

Per-Url caching? Or what do you have in mind?

Seriously though, I really want to improve the current situation regarding 
"dont look into files for mimetypes". I get that it's a severe issue for you 
performance-wise, but it is also a nasty issue for everyone trying to work 
with extension-less files.

Introducing a per-directory cache for extension-less files would be OK for the 
C++ case, but breaks again for dirs containing shebang-ed extensionless 
scripts. What else could we do?

Can you - or anyone esle - think of a easy-to-use API to find the mime stuff 
in the background? KMimeType is supposed to work from a background thread 
after all (I asked David Faure a while ago). That would probably require 
changes in the document controller, such that it calls parseDocumentsInternal 
in the background somehow. Of course, this would then mean we need to load the 
lang plugins somehow beforehand, in contrast to the lazy-loading we do 
nowadays (afair?).

What do you think?
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110610/7ef4c653/attachment.sig>