Re: Workaround for memory leak problem -- comments?

->From: cmlow@iti.gov.sg (Low Chee Meng) ->Subject: Workaround for memory leak problem -- comments? ->Date: Fri, 30 Jul 1993 04:00:17 GMT ->Reply-To: cmlow@iti.gov.sg (Low Chee Meng) ->Organization: National Computer Board, Singapore -> ->Hi, -> ->We have an application using Informix EQSL/C on Unix. This application is ->meant to run continously for many weeks in a row. Currently, it is plagued by ->memory leaks due to dynamic SQL accesses (a known Informix bug) and as a ->result bogs down and crashes every so often due to memory exhaustion. This is ->not helped by our design/code, which besides maintaining a small set of ->cursors to be accessed throughout the application lifetime, also tends to ->create, use and discard many additional cursors on demand, at a rather fast ->pace (a consequence of our O.O. design). -> ->One quick solution we came up with is to fork out a new process every time ->the application needs to serve a major task. In this way, the cursors ->can be created and discarded in the child process, which is then killed ->upon completing the task and returning contol to the parent process. ->With this scheme, the memory leaks are confined to the short-lived child ->processes and is therefore never allowed to build up to any critical limit. -> ->My question is: Is it 'safe' to fork a process that is accessing Informix? ->Will Informix be confused by the presence of the same 'cursor' (descriptor) ->in both the child and parent process? -> ->Any comments will be appreciated. -> ->Thanks and regards, -> ->CheeMeng ->-- ->--------------------------------------------------------------------- ->Chee-Meng Low (cmlow@iti.gov.sg) (fax: 65-777-3043) ->Information Technology Institute, Singapore ->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Your work-around should be stable and cause no problems. We implemented a slightly similar system, but in 4GL not ESQL/C. It ran on a network of Sun SPARCstations running Sun OS 4.1.3, using Informix SE 4.10. The main task forked off child tasks which ran in separate windows, under Sun OpenWindows. All tasks, parent and child, were interactive. We used a "memory of status" table in the database to synchronize the various tasks in the few cases where they could not run totally asynchronously. We would sometimes run two copies of the same child task from the same parent, so they were indeed using the same type of cursor, and never encountered a problem. Good luck with your project. Regards, ___________________________ O Alan __________________| R. Alan Popiel | H _________________________| Internet: | Martin Marietta, Tech Ops | H \\ | alan@den.mmc.com | P.O. Box 179, M/S 5422 | H \\ Std disclaimers apply.| Voice: | Denver, CO 80201-0179 USA | H ) | 303-977-9998 |___________________________| H / (But you knew that!) |_____________________) H /___________________________) H