Patch for mmap problem in KConfigBackEnd, Bug #72586

[Dr. Juergen Pfennig]

> >... and tried to recover from the SIGBUS. BUT THIS DOES NOT
> > WORK. Maybe it never worked?
>
> sure it never worked, it just cannot. the only way to recover is using
> longjmp.

I was aware of the longjmp family of solutions - but are you sure that they 
are C++ compliant? Is it good coding style? Is it portable? Please don't 
forget: there is no need for a SIGBUS handler any more, I simply did not
want to remove somebody else code.

Anyhow: the SIGBUS handling is second order: the pimary goal is to avoid the 
mmap problem. So shouldn't an update deal with the mmap? From the patch
that I sent, the SIGBUS handling could be completely removed - it isn't 
neccessary.
>
> > ... mmap is
> > not trivial for the kernel, maybe this patch also gives a little speed
> > improvement.
>
> somebody wants to do some measurements? i'd like to know, starting from
> which file size mmap is indeed an improvement (don't forget to include
> the malloc/free for the non-mmap case). possibly it's not worth the
> whole trouble at all, given that config files don't tend to be "large".

Yes, malloc/free can be slow, but the parsed config file gets stored in 
QStrings? For small data blocks alloca() would be better, but is it portable 
enough?

Im the 2.6 Kernel "reverse mapping" was added, because the real problem is 
munmap(). In 2.4 lists have to be searched to get info about the region that 
is to be unmapped.

Speed: Yes, I too believe that mmap can be faster. I use mmap in a video 
application that reads very large files thereby skipping parts of the 
contents. These "holes" definitely give a speed improvement. Also if you need 
some "unblocking" while processing you don't need to copy data too/from 
buffers. Both is not the problem in KConfigBackEnd. I do not believe that 
mmap is faster for files below the system page size. 

I WILL DO SOME BENCHMARKS.

Having mmap in KConfigBackEnd introduces another problem (in my video app the 
same): Imagine that you would allow the config files to be also UTF-8 encoded 
- then an inplace translation to an internal 8-Bit code would not be possible 
because the mmap data is readonly!

Anyhow, thank you for taking care of the problem and thanks for KDE!

Yours Jürgen