hi developers ...
currently pd in -rt mode tries to lock the memory to the physical memory ... this is done using the MCL_FUTURE policy, which implies that all the memory that will be allocated in future will be placed in the physical memory ... at the moment this is working fine, but when hunting random segfaults in the threaded soundfiler, i found this note in the mlockall man-page:
If MCL_FUTURE has been specified and the number of locked pages exceeds the upper limit of allowed locked pages, then the system call which caused the new mapping will fail with ENOMEM. If these new pages have been mapped by the the growing stack, then the kernel will deny stack expansion and send a SIGSEGV.
to me this seems to be the reason for the soundfiler problems, but it can reduce the stability of a working patch, so i'd suggest to find ways to solve this problem ...
possible ideas: -run mlockall(MCL_CURRENT) every once in a while ... maybe after a new object has been created or each second, 10 seconds, 1e+(add a number here) a seconds ...
-lock the specific memory region while allocating in getbytes or getalignedbytes
-on linux it might be possible to switch of overcommitment of memory in the kernel via /proc/sys/vm/overcommit_memory (don't know if this really does, what i think it's doing)
imo, MCL_FUTURE shouldn't be used to avoid this source of error ... although i'm not sure how to deal with it best, i'd prefer mlock instructions during memory allocation ...
cheers ... tim