On Thu, Mar 24, 2005 at 12:10:02AM +0100, christophe varoqui wrote: > A mempool would have to wait for another release, if at all desirable. You don't need that in userspace: glibc still supports memory pre-allocation the original way (brk) used before mmap was invented. Then your code is free to use malloc() within the amount it pre-allocated and locked - this is how the LVM2 code dodges userspace memory issues. The first thing is to re-visit the design and determine which things *have* to be done inside this tight regime and which things can be moved outside it and whether it's ever going to be possible to make it do anything useful. Everything possible needs to be moved ouside. Logging, for example, can certainly be moved outside (e.g. queued asynchronously to another process, perhaps using shmget - I've never tested this) Things the LVM2 pvmove experience taught us: Pathname lookups are not allowed (i.e. it looked impossible to guarantee never blocking while converting pathname to inode) - this is why dm tables encourage you refer to devices using major:minor You can't open any files or block devices: you need to have all the file descriptors you need prepared in advance; All reads/writes to block devices must use O_DIRECT; If you do have to read a file, you must previously have used the ioctl that turns off its atime updates; You cannot write to any files (as you can't disable the update to the inode times) Scanning for new devices/paths is never going to be able to fit within this regime so has to be handled separately. The issue is how to monitor the state of the existing paths in a table within this regime. Alasdair -- agk@xxxxxxxxxx