From owner-freebsd-current Tue Dec 22 15:51:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19779 for freebsd-current-outgoing; Tue, 22 Dec 1998 15:51:17 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19774 for ; Tue, 22 Dec 1998 15:51:13 -0800 (PST) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.1/8.9.1) id RAA69553; Tue, 22 Dec 1998 17:49:45 -0600 (CST) (envelope-from dick) Message-ID: <19981222174945.A69445@tar.com> Date: Tue, 22 Dec 1998 17:49:45 -0600 From: Richard Seaman To: Jeremy Lea Cc: freebsd-current@FreeBSD.ORG Subject: Re: Threads in WINE [was: linking against libc_r] References: <19981221093241.C546@tar.com> <19981221192734.E4060@shale.csir.co.za> <19981221114939.A5500@tar.com> <19981223001304.A319@shale.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19981223001304.A319@shale.csir.co.za>; from Jeremy Lea on Wed, Dec 23, 1998 at 12:13:05AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 23, 1998 at 12:13:05AM +0200, Jeremy Lea wrote: [snip] > > Actually, there are already two "clone" calls within Linux Threads > > right now. There is a wrapper "clone" call that wraps the clone > > syscall (see clone.S in the linux threads source). > > Well, I finally got to looking at the source. It uses clone() directly. In > fact there is no mention of libpthread at all. But there is the following > extract from wine-981211/include/threads.h: [snip] > --- > int SYSDEPS_SpawnThread( THDB *thread ) > { > #ifdef USE_THREADS > > #ifdef HAVE_CLONE_SYSCALL > if (clone( (int (*)(void *))SYSDEPS_StartThread, thread->teb.stack_top, > CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, thread ) < 0) > return -1; > /* FIXME: close the child socket in the parent process */ > /* close( thread->socket );*/ > #endif Ok. This is the wrapped clone call that is used in linux threads. It is also available in the latest glibc. The pure clone syscall only takes two arguments: the flags and the stack top. The liblinuxthreads "port" that I have posted at http://lt.tar.com wraps the rfork call into a call "thr_fork" that was originally posted to the -current list by John Dyson. It is contained in the file rf.S in that distribution, and the file internals.h has a declaration of it. I would say try using thr_fork instead of clone as follows: pid = thrfork( RFPROC | RFMEM | RFTHREAD | RFSIGSHARE, (caddr_t)thread->teb.stack_top, SYSDEPS_StartThread, (unsigned int)thread, NULL, NULL); if (pid < 0) return -1; You can just link against the libpthread that is generated by the port in liblinuxthreads as a quick way to access thr_fork, even if you don't use the other pthreads stuff. > These are the only mentions for HAVE_CLONE_SYSCALL and HAVE_RFORK. Does > this make your mind tick any? The only other condition is a reentrant libc > it would seem... The FreeBSD libc can be partly re-entrant now. In order to make the portions of libc that are designed to be re-entrannt actually behave in that manner, you need to satisfy the following three conditions: 1) You must set the libc variable (which is visible externally) __isthreaded to a non zero value. 2) You must provide an implementation of the function _spinlock which is declared in src/lib/libc/include/spinlock.h. The implementation probably needs to be "recursive" if you're going to get optimum results. _spinlock needs to override the weak aliased _spinlock that is implemented in libc as a stub function 3) You must provide implementations of flockfile, ftrylockfile, and funlockfile. Maybe also _flockfile_debug if you're going to use the debug version. These need to override the weak aliases for these functions in libc, which are also just stub functions. If you link with the libpthreads that is generated by the liblinuxthreads "port" noted above, you should get the three conditions met. Functions that are not re-entrant or thread safe yet (to the best of my knowledge) include: 1) readdir and the related dirent functions 2) localtime, asctime, ctime, etc (note that these are thread safe in libc_r, but you can't use libc_r with linuxthreads or any other kernel threads) 3) In general, any libc function for which the pthreads spec provides an "_r" function (eg. localtime_r). The "_r" functions are generally not provided, and their corresponding non "_r" functions are not thread safe. 4) I don't know about others. -- Richard Seamman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message