From mint-bounce@lists.fishpool.fi Mon Jul 5 08:45:24 2010 X-Virus-Scanned: Debian amavisd-new at pp.htv.fi From: Eero Tamminen Organization: Koti To: mint@lists.fishpool.fi Subject: Re: [MiNT] UNIXMODE defaults Date: Mon, 5 Jul 2010 15:42:32 +0300 User-Agent: KMail/1.9.9 References: <4C224E8E.9020709@atari-source.org> <201007051143.05220.oak@helsinkinet.fi> <1278330688.6162.27.camel@jetpack.demon.co.uk> In-Reply-To: <1278330688.6162.27.camel@jetpack.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201007051542.32460.oak@helsinkinet.fi> X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: oak@helsinkinet.fi Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Hi, On Monday 05 July 2010, Alan Hourihane wrote: > > I was mainly asking whether there's MiNT (and MiNTLib) specific > > information about its threads implementation (besides the old stuff on > > my ancient web page). > > MiNT & MiNTlib don't have a thread implementation. I went back to old Atari/MiNT docs and only now noticed that although they speak separately of processes and threads, the term thread seems in those docs to mean(?) the process state between fork an exec ... not what thread normally means. "Child processes created with Pvfork() share the entire program code and data space including the processor stack. The parent process is suspended until the child exits or calls Pexec()'s mode 200." Sorry for the confusion. > MiNTlib is unfortunately far from thread-safe. If MiNT doesn't thread, MiNTlib being thread-safe (locking etc) would just make it slower without any benefits... - Eero