home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / internal / 1770 < prev    next >
Encoding:
Text File  |  1992-09-04  |  1.8 KB  |  42 lines
  1. Newsgroups: comp.unix.internals
  2. Path: sparky!uunet!gatech!concert!uvaarpa!murdoch!uvacs.cs.Virginia.EDU!asw2s
  3. From: asw2s@uvacs.cs.Virginia.EDU (Alex S. Waterman)
  4. Subject: Finding the state of a process from a DD.
  5. Message-ID: <1992Sep4.134242.10948@murdoch.acc.Virginia.EDU>
  6. Followup-To: asw2s@virginia.edu
  7. Sender: usenet@murdoch.acc.Virginia.EDU
  8. Organization: University of Virginia Computer Science Department
  9. Distribution: usa
  10. Date: Fri, 4 Sep 1992 13:42:42 GMT
  11. Lines: 29
  12.  
  13. All,
  14.     I have written a device driver for a sun-4, (SunOS 4.1.1),
  15. that communicates between a user and an attached Motorola MVME167
  16. board.  The communication between the sun and the 167 is through
  17. a shared queue structure that resides in vme memory on the 167.
  18.     When the 167 has some data for the sun it places it in
  19. our shared queue and sends an interrupt to the sun.  This all works
  20. fine.  When the sun receives the interrupt he sends a psignal() to
  21. the process who owns this data, the process will then do a read()
  22. to receive it.  
  23.     This is all fine except when the process for one reason or
  24. another has died and therefor can't except the signal.  This data
  25. then sits at the front of the queue waiting to be read from a process
  26. that will never read it.  
  27.  
  28.     Is there a way to tell if the process that this data is intended
  29. for is alive??  I have saved the pointer to the proc structure, and from
  30. this can get the pid..  Right now, I am just checking to make sure that
  31. this pid is the same as the pid of the process that initiated the first
  32. call to the 167 (that initiated the processing).  It seems there must
  33. be an easier way.  Thanks!
  34.  
  35.  
  36. Also, a related question: the device driver manuals state that peek()
  37. and poke() are only to be used from the DD's probe routine.  Is there
  38. a similiar call that can be used to read/write a location from the
  39. other areas of the DD?  Thanks again.
  40.  
  41.   - Alex Waterman 
  42.