From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 17 09:17:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 90E3116A403; Tue, 17 Oct 2006 09:17:34 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: Divacky Roman Date: Tue, 17 Oct 2006 17:17:30 +0800 User-Agent: KMail/1.8.2 References: <200610150326.03279.ekkehard.morgenstern@onlinehome.de> <20061016120859.E146C2287D@snail.stack.nl> <20061017081056.GA73188@stud.fit.vutbr.cz> In-Reply-To: <20061017081056.GA73188@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610171717.30834.davidxu@freebsd.org> Cc: freebsd-hackers@freebsd.org, Ekkehard Morgenstern Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 09:17:35 -0000 On Tuesday 17 October 2006 16:10, Divacky Roman wrote: > On Mon, Oct 16, 2006 at 02:08:59PM +0200, Marco van de Voort wrote: > > > On Sunday 15 October 2006 01:32, David Xu wrote: > > > > You are going to be unable to use libc if you create raw thread in > > > > your program, libc uses pthread APIs, if you create a raw thread, > > > > your program will crash if you use any libc function which needs > > > > pthread interface. > > > > > > I don't want to link to libc. So, how do I create a raw thread? > > > > (digging deep into memory) > > > > Have a look how the linuxator emulates the clone() syscall with (IIRC) > > rfork. A limited route, but iirc it works. > > linuxolator clone() uses fork1() which is unaccessible from outside kernel. > there is a "user space implementation" of clone() in linuxthreads which > uses rfork() but rfork creates "normal processes". but you can pass flags > to rfork() thus emulation most of the needs of threads (shared memory etc.) > > roman You can use rfork() to create kernel threads, but you won't have POSIX signal and job control support in kernel, this is also one of important threading work in the past. Also rfork() does not allow you to specify user stack, you have to add some tricky code to make it safe before new thread really can do real work, plus if you want TLS to work, you have to do more work, this is why we invent THR syscalls to do all the initializing work in a single syscall, there are other problems of rfork I can not think of at the moment. David Xu