|
When delta states are no longer required, delete them by calling to
api_delete_ds or
api_prune_history. This call releases their space to free store, making it available for use in subsequent modeling. The delta state, bulletin boards, and bulletins are returned to free store, and entity records referred to in the bulletins are also released.
|
|
|
A
DELTA_STATE will be automatically deleted if it is empty and was noted by
api_part_note_state or
api_pm_note_state. The criterion for empty is no
BULLETINs. There may be one or more
BULLETIN_BOARDs, but if none have any
BULLETINs, then the
DELTA_STATE is empty.
|
|
|
Other API calls are available to prune preceding states, following states, and all states, depending upon the roll back or roll forward information needed.
|
|
|
api_delete_ds is a procedural version of the
DELTA_STATE class destructor. It releases memory associated with the
DELTA_STATE including some
BULLETIN_BOARDs,
BULLETINs and backup copies of various
ENTITYs.
|
|
|
So to release memory used by rollback, call api_delete_ds. To minimize the memory used by rollback, call
api_logging(FALSE), which causes the system to automatically delete the
DELTA_STATEs as often as possible, while still retaining rollback's role in error handling.
|
|
|
api_stop_modeler properly shuts down the modeler and frees all the memory used by
ACIS.
api_stop_modeler relies on the fact that if no
DELTA_STATEs have been deleted, then the rollback history contains pointers to all the live
ENTITYs as well as the backups. The key phrase here is "if no
DELTA_STATEs have been deleted."
|
|
|
api_prune_history also deletes delta states, but first saves the information needed by
api_stop_modeller.
|
|
|
There are three ways to clean up on exit:
|
|
|
Do not bother; let the operating system handle it.
|
|
|
Call
api_stop_modeler, and whatever else you need to clean up your application.
|
|
|
Keep track of all
DELTA_STATE and
ENTITYs and then explicitly call
api_delete_ds and
api_del_entity and whatever else is needed to clean up the application.
|
|
|
api_stop_modeler can make up for lax programming, but only if no
DELTA_STATEs have been deleted. This includes explicit deletes, deletes through
api_delete_ds, and implicit deletes due to
api_logging(FALSE).
|
|
|
The developer concerned with memory should use one of these methods:
|
|
|
|
Use
api_prune_history(ds->history_stream(), ds) after each call to
api_note_state(ds). This uses a bit more memory, but retains
api_stop_modeler's ability to clean up after some sloppy programming.
|
|
|
Use
hs->set_max_states_to_keep(number) to provide limited rollback.
|
|
|
Keep track of all
DELTA_STATE and
ENTITYs and then explicitly call
api_delete_ds and
api_del_entity and whatever else is needed to clean up the application.
|
|
|
Any of these can be used with the
compress#_bb option, which merges multiple
BULLETIN_BOARDs into one (on by default). This means that each delta state will have a single bulletin board, which saves a significant amount of memory, improves performance of roll and
API_TRIAL_BEGIN/END blocks.
|