home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / programm / 5268 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  2.7 KB
  1. Path: sparky!uunet!know!hri.com!noc.near.net!news.Brown.EDU!qt.cs.utexas.edu!cs.utexas.edu!sun-barr!ames!purdue!mentor.cc.purdue.edu!noose.ecn.purdue.edu!ecn.purdue.edu!kudva
  2. From: kudva@ecn.purdue.edu (Gautham K. Kudva)
  3. Newsgroups: comp.unix.programmer
  4. Subject: SUMMARY: Signal Handlers and malloc()
  5. Message-ID: <1992Nov13.041318.15609@noose.ecn.purdue.edu>
  6. Date: 13 Nov 92 04:13:18 GMT
  7. Sender: news@noose.ecn.purdue.edu (USENET news)
  8. Followup-To: comp.unix.programmer
  9. Organization: Purdue University Engineering Computer Network
  10. Lines: 47
  11.  
  12. Hi,
  13.     A few days ago I had posted in this group requesting some
  14. help with signal handlers. My problem was that I was calling malloc
  15. from within a signal handler, and when the signal handler was invoked
  16. while control was within a malloc call, the function had to be re-entered.
  17. Since malloc is not designed to be re-entrant, this trashed the program.
  18. I asked if there were any re-entrant versions of routines like malloc() or
  19. routines that guarded the calls by blocking signals.  Thanks to the following
  20. people for their help:
  21.  
  22. Rob Sartin
  23. Mitchell Perilstein
  24. Russell Spence
  25. Rob Quinn
  26. Christoph Badura
  27. Steve McPolin
  28. Mark Lawrence
  29.  
  30.     Everyone who responded to my post informed me that I should
  31. not attempt such stuff from within signal handlers. The suggestion was
  32. that I should restructure my code so that signal handlers would just set
  33. some flags, and the application loop should do work based on these flags. 
  34.  
  35.     Unfortunately, this is not possible for my program, since what
  36. I was really trying to achieve using signals was a crude form of threads.
  37. I am trying to write a distributed application on a workstation network. 
  38. My program has a computation thread (which will include third party
  39. code such as Linear Programming solvers) and a communication thread
  40. to enable a number of these programs to talk over a network. The 
  41. communication thread acts not only as an interface to the particular 
  42. program, but also as a routing point for messages between other processes.
  43. So it is imperative that the communication thread be invoked at regular
  44. intervals. I cannot depend on the computation thread to co-operate, since
  45. it includes third party code that won't necessarily yield control to the 
  46. communication thread periodically. 
  47.  
  48. Something like pthreads or cthreads would have been ideal for my 
  49. situation. However I haven't been able to find a single package that will run 
  50. on a mix of Sun SPARCs, HP-7000s and RS-6000s. I thought I might be
  51. able to get the same effect using singals but guess not! For the time being 
  52. I have decided to restrict myself to LWP on Suns and hope that pthreads
  53. will be available on all platforms sometime in the future (with Solaris on
  54. Suns and OSF/1 on HPs and IBMs)
  55.  
  56. Once again thanks to everyone who responded
  57. Gautham
  58. kudva@ecn.purdue.edu
  59.