home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / atari / st / tech / 4102 < prev    next >
Encoding:
Text File  |  1992-07-22  |  1.9 KB  |  40 lines

  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!zrz.tu-berlin.de!cs.tu-berlin.de!ki
  3. From: ki@cs.tu-berlin.de (Karsten Isakovic)
  4. Subject: Re: MiNT ptys
  5. Message-ID: <1992Jul22.212810.25490@cs.tu-berlin.de>
  6. Keywords: MiNT
  7. Sender: news@cs.tu-berlin.de
  8. Organization: Technical University of Berlin, Germany
  9. References: <mfg.711497130@gmd.de> <1992Jul20.072258.19480@cs.tu-berlin.de> <mfg.711660187@gmd.de>
  10. Date: Wed, 22 Jul 1992 21:28:10 GMT
  11. Lines: 27
  12.  
  13. In article <mfg.711660187@gmd.de> mfg@gmd.de (Martin Gergeleit) writes:
  14. >You are right with the analysis of my problem. But I think there is another
  15. >solution to it. With MiNTs call Fcntl(..., F_SETFD) you can force a file 
  16. >handle to be inherited to Pexeced childs. If the pty now is created at DAs boot-
  17. >time, it will be inherited to all GEM programs (and their DAs). 
  18.  
  19. But all processes 'loose' one file-handle... Shure it will work, but 
  20. the method with a second 'sub-process' does not have this restriction.
  21.  
  22.  A second problem occurs with the memory, the DA allocats while another GEM
  23.  pogram is running. If the process terminates, the memory is freed. This
  24.  
  25.  And the last big problem that you will meet (when continuing in the DA/xterm-
  26.  quest...) is that a process that was started under the desktop in your xterm
  27.  clone is in the sleeping state after you start a new GEM process ;-)
  28.  
  29. >These two problems should be handled by starting the TTP with the mode 100 of
  30. >MiNTs Pexec, I think. (correct me if I'm wrong).
  31.  
  32. This did not work for me... If you spawned the process while in the desktop,
  33. the new processes are childs of the desktop. When starting a new GEM-process,
  34. the desktop was sleeping (it? used pexec(0)...) an so did his children. 
  35. (I am not 100% shure of this.. In my DA this migt have happened because the
  36. output pipe of the paralell process was full, because the DA looked after
  37. a 'different' file-handle to read from...)
  38.  
  39. Greetings, Karsten
  40.