KPasswordDialog / KPasswordEdit

[Stefan Teleman]

On Sunday 15 January 2006 03:22, Brad Hards wrote:
> I don't follow you. The way QCA does it (actually the way Botan does it, we
> just copied it) is to mmap a temporary file. You have to zero the file
> afterwards of course, but pages that need to be swapped out won't be put on
> the swap space / swap partition - they will be put on the file.

mmap(2) reserves a memory region on the swap partition, which is part of the 
virtual memory system. this memory region will not be in-core, because 
mmap(2) does not guarantee that it allocates in-core memory. nor does it 
matter if you write 0, 'X' or PI to it. mmap(2) guarantees that the virtual 
memory pages of an object for which a valid file descriptor abstraction is 
available, will be mapped to a virtual memory resident copy of its image, and 
that I/O to this object performed through this file descriptor will be faster 
than normal stdio. however, the mmap'ed virtual memory resident copy of this 
object could still be on disk, on your swap partition. swap is usually faster 
than stdio. some pages will be swapped-in in core, some will remain on disk, 
on the raw partition designated for swap. you cannot prevent the swapper from 
swapping mmap'ed pages in or out. when you do a msync(2) on a mmap'ed object, 
(or subregion thereof) because you have modified the mmap'ed object, and you 
want to synchronize the mmap'ed image of the object with its corresponding 
image on disk, you are guaranteed to write to the region reserved on swap 
first, then to the actual object.

the only way to prevent mmap from reserving swappable memory is to call it 
with MAP_NORESERVE. this prevents mmap(2) from actually reserving *any* 
memory at all, and mmap(2) will assume that a suitable memory region is 
already available, and has been allocated for its use, with appropriate 
permissions. this implies that the caller of mmap(2) has previously created a 
shared memory region with shmget(2) and shmat(2). shared memory is not 
created within the virtual memory system, it is created in-core (more 
precisely because shared memory segments are allocated in the u_area). this 
is the main reason why all systems impose limtations on:

- the maximum size of a shared memory segment
- the maximum number of shared memory segments present in a system at any 
given time

> That isn't what the man page for mlock(2) says on my system.

programming by man page ?

can you explain what happens when you write to a mlock'ed page ? also, can you 
explain why all database engines require modifications to the shared memory 
facility of the system (usually very significant increases of the default 
limits) ? this should not be necessary for mmap(2) because mmap(2) is not 
controlled or described by any kernel configuration parameters. according to 
your assumptions, mmap(2) followed by mlock(2) should be sufficient, and 
neither of these system calls are controlled or described by any tunable 
kernel parameters.

--Stefan

-- 
Stefan Teleman          'Nobody Expects the Spanish Inquisition'
steleman at nyc.rr.com                          -Monty Python