home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / programm / 4316 < prev    next >
Encoding:
Internet Message Format  |  1992-08-15  |  2.0 KB
  1. Xref: sparky comp.unix.programmer:4316 comp.unix.misc:3236
  2. Path: sparky!uunet!sybus.sybus.com!myrddin!tscs!bailey
  3. From: bill@bailey.UUCP (Bill Glidden 882-8369)
  4. Subject: Re: Process & Signal Question
  5. Newsgroups: comp.unix.programmer,comp.unix.misc
  6. Date: 15 Aug 92 05:15:54 GMT
  7. Distribution: world
  8. Message-ID: <1657227@bailey.UUCP>
  9. Organization: Ben Bailey's Home..Tampa Fl.
  10. Sender: news@bailey.UUCP (GNEWS Version 2.0 news poster.)
  11. Lines: 26
  12.  
  13. herberj@prism.CS.ORST.EDU (John Wesley Herberg) writes:
  14. > 
  15. > 1 - Is there an effecient way for one process to know if another is running 
  16. > when the only thing you know about it is its name.  The way I'm doing it now
  17. > is grabbing info for all the processes by using pstat(an HP-UX call) &
  18. > searching through that info for a matching process name.  Is there some type 
  19. > of call I could do on the executable to see if it is in use.  I noticed
  20. > make doesn't allow you to update a file when its being used - how does it know?
  21. > 
  22. Make knows the executable is in use because when you fopen or open a file for
  23. create and it is in use, the operating system returns an error condition to
  24. the calling program. Of course, I don't recommend this for your situation.
  25.  
  26. > 2 - In Marc Rochkind's "Advanced Unix Programming", he says it's not a good
  27. > idea to use the SIGUSR1/2 signals for user defined signals.  Why?  All I want 
  28. > to do is notify another process of an event & I don't want the overhead of a
  29. > msg, shared mem, etc.  Seems to me this would be the most effecient way.  Is
  30. > there something else I should know about using signals?
  31. > 
  32. I believe the point he is trying to make (on page 211) is that a signal is
  33. not recommended for inter-process communication, because signals have no
  34. information content. As an event trigger, though, I think that a signal
  35. works just fine if you are willing to code the overhead of catching and
  36. resetting it. Also, how often will you be signalling the other process?
  37. If it is more than once, remember to reset the signal catching function
  38. for SIGUSR1 immediately upon entering the signal catching function.
  39.