|
|
|
#include <Iguana/Utilities/classlib/utils/LowMemoryPool.h>
Static Public Member Functions | |
| static void | add (unsigned kbytes, Callback notifier, bool last=false) |
| static unsigned | pools (void) |
| static void | reset (void) |
| static unsigned | size (unsigned pool) |
Private Member Functions | |
| LowMemoryPool (const LowMemoryPool &) | |
| LowMemoryPool (unsigned kbytes, Callback notifier, bool last) | |
| LowMemoryPool & | operator= (const LowMemoryPool &) |
| ~LowMemoryPool (void) | |
Static Private Member Functions | |
| static bool | pop (void) |
| static void | trigger (void) |
Private Attributes | |
| Callback | m_callback |
| bool | m_last |
| LowMemoryPool * | m_next |
| new_handler | m_old_handler |
| char * | m_reserve |
| unsigned | m_size |
Static Private Attributes | |
| static LowMemoryPool * | s_pools |
This class allows the application to allocate memory reserve pools. Whenever a new pool is added, a new memory reserve is added to the top of internal stack, and a new handler is registered. When that handler is invoked, the top pool is freed and the application callback invoked. If the last pool is freed and it is marked as a last resort pool, std::bad_alloc is thrown; this allows parts of the program allocate last resort reserves without knowing whether others parts have already done so. By adding several pools in a row the application can create a cascade effect: the later pools will fall back on the earlier ones.
The application callback should not throw, except perhaps a std::bad_alloc. This limitation is caused by global new having a throw specification of std::bad_alloc. An attempt to throw any other exception will automatically be killed by the compiler run-time (and results in a call to unexpected()).
If the application is interactive, it should allocate two or three low-memory pools. The first and smallest should be marked as a last resort pool. The pool should be large enough to allow a graceful unwind and shutdown back to the main program. Note that exception handling may require some amount of memory, especially if no exceptions have yet been thrown in that part of the program -- so by the time `operator new' throws `stdbad_alloc', it may no longer be possible to process that exception. Unless the program can recover substantial amount of unused resources, it is unlikely to make sense to continue execution after the last pool is freed. If the program does continue, it should re-allocate the reserve pools before doing anything else so that it can get back to a fault tolerant state (if the re-allocation fails, it probably is impossible to continue anyway). Nevertheless, the program should attempt to write its state to a recovery file to ensure that no work is lost. The best way to to achieve this is to preallocate the resources required (files, memory) when creating or opening the document, and them simply writing out the information on crash.
The second and larger pool should not throw any exceptions. The application hook should notify the user that memory is running low, and encourage the user to save the application state immediately, and if possible, to shut down unnecessary application functions (windows, disable allocation-intesive operations such opening new documents and other such things). The hook could also reap unused resources or caches if there are any. If some lengthy operation is going on (and consuming substantial amounts of memory), the hook should set an indicator that long operations inspect regularly such that the operation should be cancelled as soon as possible. Note that it is not possible to throw a special warning exception; it is however possible to notify pre-registered observers. The second pool should be large enough for the application to be able to save its state if the warning is heeded immediately (and provided that allocation-intensive operations are cancelled).
The third and largest pool should act as a first memory-shortage warning. The application hook should advise the user to disable unnecessary application features and encourage her to save the work as soon as possible. It may not yet be necessary to disable any application features at this point. Like the second hook, this one should set an indicator for allocation-intensive tasks to stop.
If the application uses several layers of pools as described above and gracefully returns to normal operation, it should reallocate its pools rather quickly. For an interactive application this can be done easily: in event-loop ``idle'' hooks, timer callbacks, or combinations of both (e.g. 15 second timer followed by wait until all user interface events are drained). When the second pool is released, the application hook should disable application features that are likely to be allocation-intensive (such as opening or creating new documents). Once the pool reallocation succeeds (this may not be possible on the first attempt as user may not have yet had the possibility of responding to the application prompt), the disabled features can be restored to normal. An easy way of achieving all this is to check, for all menu items, tool bar buttons etc., the state of some global memory allocation status indicators. This will limit the amount direct state manipulation that is required.
Finally, please note that allocating the pools may throw a std::bad_alloc. You should protect your program logic, and in particular the pool cascade allocation against this (for example, your last resort pool may get released when you allocate the next-larger pool).
Definition at line 107 of file LowMemoryPool.h.
| lat::LowMemoryPool::~LowMemoryPool | ( | void | ) | [private] |
| lat::LowMemoryPool::LowMemoryPool | ( | const LowMemoryPool & | ) | [private] |
| static void lat::LowMemoryPool::add | ( | unsigned | kbytes, | |
| Callback | notifier, | |||
| bool | last = false | |||
| ) | [static] |
Referenced by IgOnLowMemoryService::init().
| LowMemoryPool& lat::LowMemoryPool::operator= | ( | const LowMemoryPool & | ) | [private] |
| static unsigned lat::LowMemoryPool::pools | ( | void | ) | [static] |
Referenced by IgOnLowMemoryService::init().
| static unsigned lat::LowMemoryPool::size | ( | unsigned | pool | ) | [static] |
Callback lat::LowMemoryPool::m_callback [private] |
Definition at line 126 of file LowMemoryPool.h.
bool lat::LowMemoryPool::m_last [private] |
Definition at line 132 of file LowMemoryPool.h.
LowMemoryPool* lat::LowMemoryPool::m_next [private] |
Definition at line 123 of file LowMemoryPool.h.
new_handler lat::LowMemoryPool::m_old_handler [private] |
Definition at line 130 of file LowMemoryPool.h.
char* lat::LowMemoryPool::m_reserve [private] |
Definition at line 124 of file LowMemoryPool.h.
unsigned lat::LowMemoryPool::m_size [private] |
Definition at line 125 of file LowMemoryPool.h.
LowMemoryPool* lat::LowMemoryPool::s_pools [static, private] |
Definition at line 134 of file LowMemoryPool.h.
1.5.4