roger@zuken.co.jp (Roger Meunier) (08/09/90)
When a C++ program exits, it calls a list of destructors to clean up static data. But what happens when exit() is called after fork()? I ran into a problem with HP's implementation of Motif 1.0. For the XmText widget, they allow Chinese character input by setting up a connection with an input server. Apparently, they fork() the server on the first XmCreateText(). I noticed that in one of my applications, it was taking an extremely long time to create the first text widget (8+ sec.), and that core was being dumped during the creation. Looking at the core file with cdb, I noticed that exit() was being called from the routine that did the fork(), and that subsequently all my static destructors were being called, including one that caused the core to be dumped (it was calling XCloseDisplay()!). Why the *child* process should be trying to do this is beyond me. Has anyone else run into similar problems when fork()'ing in a C++ environment? Is this a design problem with the C++ static object clean-up strategy, or is HP's implementation of nlio forgetting to take C++ into account, or both? -- Roger Meunier @ Zuken, Inc. Yokohama, Japan (roger@zuken.co.jp)