Re: Pexec mode 4 and 104

[Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>]

evanlang@uss.lonestar.org (Evan Langlois) writes:

|> I have a couple questions about Pexec 4 and Pexec 104.

|> If the parent program passes an inheritable file handle to the child,
|> can the child make use of the handle, even if the file wasn't opened until
|> after the Pexec(104) took place?  So, does WHEN a file is opened have
|> any significance?  I would think that only file handles that were opened at
|> the time of Pexec(4/104) would be inheritable.  Is this so?

Yes, because a file handle that does not refer to an open file isn't a
file handle :-)

|> Does memory sharing work both ways?

Yes, all the memory (including the new basepage and enviroment) is
attached to both processes at the time Pexec is called.

|> What about GEM?  Can a child executed through Pexec 4 or 104 use its
|> parent's application id and make AES calls as if it was the parent since
|> it shares all its memory?  Or woudl the child have to open a new appl_id
|> with appl_init()?  This would be inconvienient for my purposes since I
|> would also need an evnt_multi() loop and I wanted to block waiting on
|> Pmsg() calls, not evnt_multi() - I'd have to poll for one or the other :-(

I don't know, but i don't think you must call appl_init again.

|> What about  malloc?  If the child app calls's the parent's malloc(), and
|> that malloc() requests more memory from teh OS, then it will be called from
|> the context of the new process.  Wouldn't this mess up the malloc() arena?

Yes, you should never use malloc() in both processes, as it isn't
thread safe, and the new memory is only attached to the calling
process.

-- 
Andreas Schwab                                      "And now for something
schwab@ls5.informatik.uni-dortmund.de                completely different"