Patch for mmap problem in KConfigBackEnd, Bug #72586
Dr. Juergen Pfennig
info at j-pfennig.de
Fri Jan 16 09:31:26 GMT 2004
> >... 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
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
> > ... 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
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!
More information about the kde-core-devel