home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11804 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  2.4 KB

  1. Path: sparky!uunet!darwin.sura.net!mips!swrinde!sdd.hp.com!hplabs!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
  2. From: kers@hplb.hpl.hp.com (Chris Dollin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: How to avoid calling destructor twice after fork()?
  5. Message-ID: <KERS.92Jul30173512@cdollin.hpl.hp.com>
  6. Date: 30 Jul 92 16:35:12 GMT
  7. References: <1992Jul29.180655.4716@cis.ohio-state.edu> <1992Jul30.120150.1507@actrix.gen.nz>
  8. Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
  9. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  10. Lines: 95
  11. In-Reply-To: Bruce.Hoult@bbs.actrix.gen.nz's message of 30 Jul 92 12:01:50 GMT
  12. Nntp-Posting-Host: cdollin.hpl.hp.com
  13.  
  14. In article ... Bruce.Hoult@bbs.actrix.gen.nz writes:
  15.  
  16.    [quoting someone else]
  17.    > I am using fork() system call in my C++ program. The problem is that each
  18.    > calling of fork() creates a copy of calling process. The problem is any
  19.    > instances created and not destroyed before fork() calling will be 
  20.    > destroyed twice. [comiited]
  21.  
  22.    What's the problem?  After the fork you've got two seperate objects in
  23.    different processes and running the destructor on both of them is the
  24.    correct thing to do -- the only possible problem is that the fork()
  25.    call effectively does a default operator= to create the second copy
  26.    instead of using any operator= that you've defined.
  27.  
  28. That's all very well, but what if the objects are hanging on to an external
  29. resource, such that the destructor does something *external*? For example, a
  30. Window object might have an X window handle, and the destructor might destroy
  31. the window. What happens if you try and destroy a destroyed window? Will the
  32. code abort (so what happens to the other destructores - do they get run, too)?
  33. Or will the server happily delete a new window that's been allocated the same
  34. handle? The same with a lock file object - it might be a new lock (probably
  35. shouldn't be, but it might). 
  36.  
  37. No, it's not that easy.
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.    -- 
  101.    Bruce.Hoult@bbs.actrix.gen.nz   Twisted pair: +64 4 477 2116
  102.    BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
  103.    "Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
  104.    hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"
  105. --
  106.  
  107. Regards,    | It's strange how you suddenly discover bizarre and dangerous
  108. Kers.       | holes in your knowledge.  I fell down one today. - Steve Knight
  109.