Jesus Cea Avion <jcea@argo.es> writes: > Some weeks ago I asked the list about mmap access arbitration in > NNTPCACHE, since my investigation showed that interprocess communication > in nntpcache was not protected in any way against race conditions. It shouldn't need to be. Here's why. The copy on write semantics protect regular malloc structures. Shared memory only ever has one process (at a time) that allocates, frees data, or modifies pointers (nntpcache-update). All other processes are readers, or at worst do psuedo atomic variable updates (e.g newsgroup->lo_xover = n), where collisions are unimportant. No shared memory linked to walkable structures is ever free'd. This is by design. There is one place where these rules are not followed and should be -- task_info_new(). However, it does seem somewhat unlikely that this is the cause of any memory curruption problems you are seeing. The race condition would be as follows: nntpcache-update would have to be in the process of shared memory allocation at the moment a new nntpcache task was created and was in the shared memory mallocer. This may seem a common occurance, but with the exception of the initial run, it is not, for shared memory is only allocated by nntpcache-update on detection of a new newsgroup. The chance of the task giving up its quantum at that moment seems remote. pre-allocating a shared memory array for task_info_new is the way to fix this problem. Cheers, Julian.
