From mint-bounce@lists.fishpool.fi Mon Feb 1 13:15:55 2010 Message-ID: <4B671946.5040305@gandon.org> Date: Mon, 01 Feb 2010 19:11:18 +0100 From: Benjamin Gandon User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= CC: mint@lists.fishpool.fi Subject: Re: [MiNT] half off topic kernel Pexec/Pterm discussion (was: Freeing child's base page) References: <4B5F9E76.7070205@freesbee.fr> <4B6010B7.70306@freesbee.fr> <4B60189C.2000806@freesbee.fr> In-Reply-To: <4B60189C.2000806@freesbee.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: benjamin.mint@gandon.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id o11IFtg3001496 Hi there, Vincent Rivière a écrit : > Miro Kropacek wrote : >> So, if I understand it correctly, when Pexec() returns (using Pterm >> or Pterm0) : >> >> 1. all dynamic memory (using M[x]alloc) is returned back to OS, all >> opened files are closed > > In the normal mode PE_LOADGO (0), I think it is true. But I don't know > hot it behaves in other modes. This is actually true in all modes. The only difference with Pexec() mode 3 is that the containing memory block is "tagged" as belonging to the parent. Only this. So upon child completion, this block does not belong to the child resources that are all freed by Pterm(). >> 2. its text/data/bss segment is still intact, waiting for our Mfree() >> call (and this can be changed by using Pexec (6, ...) but don't want >> it of course) > > Probably true in mode PE_LOAD (3). Yes : http://removers.free.fr/wikipendium/wakka.php?wiki=Pexec%28%29 > >> 3. static variables are in data segment, i.e. point 2 applies here, >> i.e. we can use it as long as basepage isn't free'd > > Yes, sure. > >> However, it seems that MiNT handle special executable flags to share >> the text segment among several process, but I never tried them as >> this is a very specific case. >> >> You mean PE_NOSHARE mode? This is default off, i.e. child's memory is >> shared with parent, so no worries here. > > Yes, this flag. But I didn't understand that flag like you. I > understood it was about sharing the text segment between several > process of the same executable to save the identical RAM. In other > words, using the text segment like a shared library (useful for sh and > make). I don't know if this is still well supported by the kernel and > the binutils. I don't know any system call that enables this running several processes with shared TEXT segment. Does anyone knows about this? In this regards, the hack described by Jo looks like a pretty clever turnaround to me: > It's > possible to create just a basepage with Pexec, and set it to point to > the TEXT-segment of another process (threading). IIRC this technique is > used in some of Ozk's assembly-programs, like TextView! IMO this could even be adopted as a kernel standard for running several processes with shared TEXT segment. As far as I know, this would require a new system call, or a new Pexec() mode, though. Advice from a Kernel Guru might help here : - is there anything in POSIX standards about running several processes with "physically" shared code? - is anything wanted or planned in MiNT about this feature?