home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / programm / 4330 < prev    next >
Encoding:
Internet Message Format  |  1992-08-16  |  2.6 KB
  1. Xref: sparky comp.unix.programmer:4330 comp.unix.misc:3253
  2. Newsgroups: comp.unix.programmer,comp.unix.misc
  3. Path: sparky!uunet!uunet.ca!geac!torag!zooid!ross
  4. From: Ross Ridge <ross@zooid.guild.org>
  5. Subject: Re: Process & Signal Question
  6. Organization: ZOOiD BBS
  7. Date: Sun, 16 Aug 1992 22:30:01 GMT
  8. Message-ID: <1992Aug16.223001.23257@zooid.guild.org>
  9. References: <1657227@bailey.UUCP>
  10. Lines: 54
  11.  
  12. herberj@prism.CS.ORST.EDU (John Wesley Herberg) writes:
  13. >1 - Is there an effecient way for one process to know if another is running 
  14. >when the only thing you know about it is its name.  The way I'm doing it now
  15. >is grabbing info for all the processes by using pstat(an HP-UX call) &
  16. >searching through that info for a matching process name.  Is there some type 
  17. >of call I could do on the executable to see if it is in use.  I noticed
  18. >make doesn't allow you to update a file when its being used - how does it know?
  19.  
  20. bill@bailey.UUCP (Bill Glidden 882-8369) writes:
  21. >Make knows the executable is in use because when you fopen or open a file for
  22. >create and it is in use, the operating system returns an error condition to
  23. >the calling program. Of course, I don't recommend this for your situation.
  24.  
  25. If you have write permission for the executable this should work:
  26.  
  27.     int fd;
  28.  
  29.     fd = open("foo", O_WRONLY);
  30.     if (fd == -1) 
  31.         if (errno == ETXTBSY) 
  32.             printf("foo is running.\n");
  33.         else 
  34.             perror("foo");
  35.     else {
  36.         close(fd);
  37.         printf("foo isn't running.\n");
  38.     }
  39.  
  40.  
  41. >>2 - In Marc Rochkind's "Advanced Unix Programming", he says it's not a good
  42. >>idea to use the SIGUSR1/2 signals for user defined signals.  Why?  All I want 
  43. >>to do is notify another process of an event & I don't want the overhead of a
  44. >>msg, shared mem, etc.  Seems to me this would be the most effecient way.  Is
  45. >>there something else I should know about using signals?
  46.  
  47. >As an event trigger, though, I think that a signal works just fine if you
  48. >are willing to code the overhead of catching and resetting it.  Also, how
  49. >often will you be signalling the other process?  If it is more than once,
  50. >remember to reset the signal catching function for SIGUSR1 immediately upon
  51. >entering the signal catching function.
  52.  
  53. It's possible to receive a second signal after you signal catching
  54. function starts but before function has a chance to reset the signal
  55. thus killing the process.  You should use functions like sigset or
  56. their BSD equivilent to avoid this.  Also note it's possible to lose
  57. signals if one arrives while another (of the same type) is pending.
  58.  
  59.                             Ross Ridge
  60.  
  61. -- 
  62. Ross Ridge - The Great HTMU                         l/     //
  63.                                     [OO][oo]
  64. ross@zooid.guild.org                            /()\/()/
  65. uunet.ca!zooid!ross                             db     //
  66.