home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / windows / x / 14695 < prev    next >
Encoding:
Text File  |  1992-07-31  |  3.0 KB  |  70 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!era!feit
  3. From: feit@ERA.COM (Mark Feit)
  4. Subject: Re: fork and X
  5. Message-ID: <1992Jul31.145417.8778@ERA.COM>
  6. Sender: feit@ERA.COM (Mark Feit)
  7. Organization: Engineering Research Associates, Vienna, VA
  8. Date: Fri, 31 Jul 1992 14:54:17 GMT
  9. Lines: 59
  10.  
  11. On comp.windows.x, tomasc@lionfish.tds.kth.se (Tomas Carlsson) posts:
  12.  > I'm writing a program that needs to spawn children using a fork
  13.  > and be able to talk to them using a pipe. My problems arise when
  14.  > I want to spawn a second child. The first one is no problem.
  15.  > 
  16.  > The first (X Windows-) thing a child does is make a fontcursor
  17.  > and a pointergrab. This works fine for the first child but the
  18.  > second one kills the whole family. I get these errors before
  19.  > everything exits:
  20.  > 
  21.  > X Error of failed request:  BadIDChoice (invalid resource ID
  22.  >   chosen for this connection)
  23.  > X Error of failed request:  BadCursor (invalid Cursor parameter)
  24.  
  25. Resource IDs are selected on the client side by an Xlib-internal
  26. routine called _XAllocID, which allocates a unique 32-bit ID based on
  27. some bitmasks acquired when the connection to the server was opened
  28. and a counter which gets incremented on each call.  Whenever you make
  29. an Xlib call that creates a server resource (i.e., one from the
  30. XCreate* family), the routine calls _XAllocID for a new resource
  31. number before shipping its request off to the server.  (IDs are a lot
  32. like files: The file system may create the file itself, but _you_ get
  33. to pick a name to identify it.)
  34.  
  35. Your problem crops up as a result of the child processes having
  36. separate copies of _XAllocID's internal counter.  For example, if the
  37. last resource ID allocated before you fork was abcd028, the first
  38. child will allocate abcd029.  When you fork again (assuming no
  39. intervening calls to _XAllocID), the second child will get the same
  40. internal counter and will try to create something with an ID of
  41. abcd029, which the server chokes on because it's already been
  42. allocated.
  43.  
  44. Off the top of my head, I can think of two solutions.
  45.  
  46.     - Allocate your resources before you fork and don't allocate
  47.       anything in the children.
  48.  
  49.     - If you're not forking the same thing several times and your
  50.       children allocate their own space to work with, switch to
  51.       lightweight processes.  (Less overhead there, too.)
  52.  
  53. I've never really given much thought to how X programs that fork or
  54. are run on multiprocessor boxes should work, and perhaps I should
  55. since I may wind up having to deal with it sometime.  I suppose
  56. isolating one copy if Xlib into an RPC service might be one way to go
  57. about it.  Would anyone from the parallel computing world care to
  58. comment on how they handle things like this?
  59.  
  60.                         - Mark
  61.  
  62.  ................................. .................................
  63. : Mark A. Feit, Software Engineer : Internet: feit@era.com          :
  64. : Engineering Research Associates : USENET: ...!uunet!era!feit      :
  65.  ................................. .................................
  66.  "Software development is 10% science, 25% ingenuity and 65% getting
  67.            the ingenuity to work with the science."
  68.  
  69.  
  70.