NO

Author Topic: Threads and memory  (Read 5298 times)

Alessio

  • Guest
Threads and memory
« on: March 12, 2008, 01:22:23 PM »
Hi,

I've a program that starts a new thread.
This new thread call an exported function of an already loaded dll.
This dll do some operations through malloc\free allocators.

I'm wondering if I quit main program through WM_CLOSE message ( X button ) and thread is running, who cares about malloced memory ?
Me ?
Windows ?
None of above ?

Thanks.

Offline Stefan Pendl

  • Global Moderator
  • Member
  • *****
  • Posts: 582
    • Homepage
Re: Threads and memory
« Reply #1 on: March 12, 2008, 04:18:43 PM »
Hi,

I've a program that starts a new thread.
This new thread call an exported function of an already loaded dll.
This dll do some operations through malloc\free allocators.

I'm wondering if I quit main program through WM_CLOSE message ( X button ) and thread is running, who cares about malloced memory ?
Me ?
Windows ?
None of above ?

Thanks.
Since C is not a managed language it is You ;)
---
Stefan

Proud member of the UltraDefrag Development Team

Alessio

  • Guest
Re: Threads and memory
« Reply #2 on: March 13, 2008, 03:21:01 AM »
Thank you, but if memory is not freed and program quit, which problems can occurs ?
Memory cannot be used again by other applications ?

(Sorry if this question seems off topic, maybe I must read some O.S. architecture books)

Alessio.

benjaminmaggi

  • Guest
Re: Threads and memory
« Reply #3 on: March 13, 2008, 05:16:50 PM »
The DLL should trap the dettach process (unloading) DLL_PROCESS_DETACH and DLL_THREAD_DETACH (thread is exiting) If you wrote the DLL you should implement those functions please have a look at this sample code:

Code: [Select]
//BOOL WINAPI __declspec(dllexport) LibMain(HINSTANCE hDLLInst, DWORD fdwReason, LPVOID lpvReserved)
// or:
BOOL APIENTRY DllMain(HINSTANCE Inst, DWORD reason, LPVOID reserved) // <-- this works with DevCPP
{
    switch (reason)
    {
        case DLL_PROCESS_ATTACH:
            // The DLL is being loaded for the first time by a given process.
            // Perform per-process initialization here.  If the initialization
            // is successful, return TRUE; if unsuccessful, return FALSE.
            break;

        case DLL_PROCESS_DETACH:
            // The DLL is being unloaded by a given process.  Do any
            // per-process clean up here, such as undoing what was done in
            // DLL_PROCESS_ATTACH.  The return value is ignored.
            break;

        case DLL_THREAD_ATTACH:
            // A thread is being created in a process that has already loaded
            // this DLL.  Perform any per-thread initialization here.  The
            // return value is ignored.
            break;

case DLL_THREAD_DETACH:
            // A thread is exiting cleanly in a process that has already
            // loaded this DLL.  Perform any per-thread clean up here.  The
            // return value is ignored.
            break;
    }
    return TRUE;
}

The DLL should keep an eye, if it mallocs space on behalf other thread it should take actions after that process has ended.
« Last Edit: March 13, 2008, 05:22:20 PM by benjaminmaggi »

Offline Stefan Pendl

  • Global Moderator
  • Member
  • *****
  • Posts: 582
    • Homepage
Re: Threads and memory
« Reply #4 on: March 13, 2008, 06:22:22 PM »
Thank you, but if memory is not freed and program quit, which problems can occurs ?
Memory cannot be used again by other applications ?
Not freeing the memory used will result in memory leaks, Windows has a garbage collection, but it is not the best.

The results are unpredictable, but a crash could be one result.
---
Stefan

Proud member of the UltraDefrag Development Team

severach

  • Guest
Re: Threads and memory
« Reply #5 on: March 15, 2008, 03:11:02 AM »
Quick overview of how processes exit on Windows XP

Anything on your local heap is cleaned up by Windows on exit. You want to free that memory to prevent memory problems in long runs but if you're going to exit it isn't necessary to free every pointer.

It is a good policy to free your pointers anyways. Various Windows are differently abled in automatically freeing what you don't. Other operating systems and environments may have radically different cleanup abilities. You may have allocated things that cannot be automatically cleaned up. Your lack of cleanup may not cause any trouble now but will when your program gets bigger and more popular memory problems may come up and you've long forgotten that your code didn't clean things up.