- [Nix] another doubt for the possible memory leak problem - 3 Updates
- std::thread - DESPERATE NEED HELP!!! - 1 Update
- Weird use of maps. - 1 Update
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 13 09:37PM +0300 On 13.09.2019 20:10, Soviet_Mario wrote: > could not be safely freed on relevant client termination. > If instead the memory is somewhat attributed to the caller and not to > the library itself, it can be safely freed. Surprise-surprise, other people have worried about such things in the past, and have come up with a notion of something called "process", about 50 years ago. The memory allocated by malloc() becomes part of the process memory space and is owned by the process; such memory will be released and recycled when the OS terminates the process. The "ownership" of the memory inside the process is not really relevant here, as all shared libraries loaded into the process see the same process memory space; if anything, the memory is "owned" by the memory manager behind malloc(). In unix/Linux there is typically only one such memory manager in the process, which makes it possible in the first place to design such interfaces as scandir() (in Windows different DLL-s can easily contain or access different malloc() memory managers, making things more interesting). |
| Soviet_Mario <SovietMario@CCCP.MIR>: Sep 14 12:51AM +0200 Il 13/09/19 20:29, Keith Thompson ha scritto: > two simultaneously running processes using a library, even if > they're instances of the same program, generally can't see each > other's memory. ok, thanks ... very clear till here > Local data in a library function is allocated on > the calling process's stack. here I have a doubt instead. As we were talking about malloc and dynamic memory, why the "stack" ? The stack is that area accessed by bp register for parameters and return values (and auto variables), isnt' it ? Many years ago I used to read about the "heap" for async. allocated memory, like the one got by malloc ... > Again, this is more about the OS than about anything specified yes, that's why I put [Nix] in the intro of the question. I was sure it had necessarily to do with the memory manager of the OS. In the end a memory leak in the process should bubble up until it. But, to sum up : a process should not be able, willy nilly, if using plain malloc and no particular privilege or other tecniques (i.g. to become a daemon and remain loaded), to produce a memory leak. -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Sep 14 12:59AM +0200 Il 13/09/19 20:36, Scott Lurndal ha scritto: >> unloading), but can have an unpredictable lifetime and thus >> survive "the" caller. > Keith has addressed this. yes, seen > If you need to store it in other formats, you might consider using > nftw(3) and you can store the data once, rather than copying what > scandir returns. yes, thanks. I'm reading the man page and seeing it allows for a callback to receive EACH data to do whatever it wants with them. To be actually useful for long term storage, I'd need a way to at least enumerate, or better, get the mere number of inodes of the given type to know in advance how much memory to allocate, before having the callback called by nftw. I'd very much prefer a scenario when I try to allocate all (at least at a directory level) of the needed entries or none at all an fail, rather than allocating one by one and potentially run out of memory at some point halfway of the scan, leaving the stored tree in a non consistent state (and then having to free the half stored and so). I have to find other functions to get the number of files (or subfolders, separately) in a given folder without actually "stat"-ing anything. -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 13 12:53PM -0700 On 9/11/2019 11:16 AM, Szyk Cech wrote: > unique_lock lock(mAccessMutex); > --mCounter; > if(mCounter < 0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > mWaitingCondition.wait(lock); > } This is not how a condition variable was designed to be used. In fact, iirc, a conforming condvar impl does not even need to block, it can just yield the thread and continue on. You need to contain your wait predicate in a _loop_. The dec function from my example: __________________________ void dec() // wait { std::unique_lock<std::mutex> lock(m_mutex); while (m_count == 0) m_cond.wait(lock); --m_count; } __________________________ Notice the while loop? |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 13 03:04PM -0400 On 9/13/19 11:49 AM, Manfred wrote: >> without bothering to consider whether it was actually needed. > An abstract reason (i.e. with no sight of the code) is to distinguish > between an empty message and a non existing message: No entry is placed into the message map until the first part of a message is received (and even then, only if it's a multi-part message - single-part messages are handled immediately rather than being saved up waiting for the remaining parts). Therefore, there will always be at least one part of one message for every entry in the map. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment