home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / database / informix / 3066 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.3 KB
  1. Path: sparky!uunet!oracle!pyramid!infmx!davek
  2. From: davek@informix.com (David Kosenko)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: ESQL/C -- sqlturbo and sqlexit()
  5. Message-ID: <1993Jan27.153410.16789@informix.com>
  6. Date: 27 Jan 93 15:34:10 GMT
  7. References: <FORNEY.93Jan19085549@vega.bsdsun> <1993Jan21.090631.17764@pyra.co.uk> <C1Horv.1MH@nit.pactel.com>
  8. Sender: news@informix.com (Usenet News)
  9. Organization: Informix Software, Inc.
  10. Lines: 55
  11.  
  12. Eric Pederson writes:
  13. >It seems that sqlexit() in ESQL/C version 4.x is doing a blocking
  14. >wait() instead of a waitpid() or a non-blocking wait3() or wait4().
  15. >If I want to sqlexit() before my other children have died, then the sqlexit()
  16. >hangs.  Also, while it is hanging, I do a "ps" and find that sqlturbo is
  17. >*still* running.  Isn't it supposed to wait() *after* the kill?  If (while it
  18. >is hanging) I kill my application with a SEGV signal, I get the following in 
  19. >an "adb" traceback:
  20. >
  21. >_wait4(?)
  22. >__DYNAMIC(0xefffe22c,0x0,0x2a9400,0x2,0x10,0x0)    + 4
  23. >_killbackend(0x5035,0x0,0x0,0x10,0x2b2a68,0xc) + 34
  24. >_sqlexit(0x1,0x1f,0xefffe318,0x2c38d0,0xef7ea760,0x1) +    4
  25. >
  26. >Is this fixed in version 5.0 or is there a way around using sqlexit()
  27. >to stop the sqlturbo process when you are finished with ESQL?
  28.  
  29. Well, let's take a look at what sqlexit() actually does.  This is based
  30. on 5.0 behavior, though I don't think it changed from 4.x.
  31.  
  32. As you can see from the stack trace, sqlexit() calls  killbackend(); in fact,
  33. it does little else.  killbackend() does all the work.  What it does is to
  34. close the input and output pipe that is used to communicate with the server.
  35. It then does a wait() until the pid returned is that of the spawned server.
  36. This wait is done inside a while loop, which will not terminate until that
  37. child process has died.  Note that there is no kill involved.
  38.  
  39. On the server end, closing the pipes from the client end should generate either
  40. an eof from the read side (when the server reads from the pipe to see what to
  41. do next - this is a blocked read), or a SIGPIPE when it tries to write to a
  42. pipe whose other end is closed.  The first case should be straightforward;
  43. the second can be problemmatic.
  44.  
  45. The SIGPIPE generated by the write to the pipe can only occur when a write
  46. is initiated by the server.  If you should attempt to perform an sqlexit()
  47. while the server is off doing some work (by catching a SIGINT in your app,
  48. and calling sqlexit() as part of your signal handler) you could wind up in
  49. some trouble, because the server is merrily off doing its work, and will
  50. not notice the closed pipes until it attempts to send something back.  If
  51. it is involved in a complex operation (or the OnLine system is hung for
  52. one reason or another), the write will not be happening right away, and your
  53. app will be sitting on that wait until the server finishes what it is doing.
  54.  
  55. The best way around this is to always start any signal handling with an 
  56. sqlbreak().  That will interrupt the server asap, at which point it can see
  57. the sqlexit() stuff and clean up properly.  
  58.  
  59.  
  60.  
  61. Dave
  62. -- 
  63. Disclaimer: These opinions are not those of Informix Software, Inc.
  64. **************************************************************************
  65. "I look back with some satisfaction on what an idiot I was when I was 25,
  66.  but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney
  67.