From owner-freebsd-current Fri Jan 22 06:32:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA22624 for freebsd-current-outgoing; Fri, 22 Jan 1999 06:30:38 -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 GAA22576 for ; Fri, 22 Jan 1999 06:30:35 -0800 (PST) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.2/8.9.1) id IAA75697; Fri, 22 Jan 1999 08:30:21 -0600 (CST) (envelope-from dick) Date: Fri, 22 Jan 1999 08:30:21 -0600 From: "Richard Seaman, Jr." To: "Russell L. Carter" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Using LinuxThreads Message-ID: <19990122083021.E5495@tar.com> References: <199901220239.TAA06788@psf.Pinyon.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199901220239.TAA06788@psf.Pinyon.ORG>; from Russell L. Carter on Thu, Jan 21, 1999 at 07:39:28PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 21, 1999 at 07:39:28PM -0700, Russell L. Carter wrote: > dick@tar.com said: > %libc_r could be modified so that is doesn't replace libc, but rather > %is an addon, comparable to the kernel threaded libc case. But, it > %would involve a bit of work. > > I thought so at first, but then I had to look at wait4 today and > now I'm not so sure. At least some of libc_r is very closely > tied to the uthread scheduler: Sure it is. But, I don't see why that prevents the possibility of leaving libc in place and having libc_r just be an add on (not that I'm advocating this). Taking your example, in libc the syscall is implemented as _wait4, and wait4 is a weak alias to _wait4. If you replaced _thread_sys_wait4 below with _wait4 instead, and put the resulting code in a library separate from libc (eg. in a "new" libc_r) along with the uthread scheduling code and the rest of the uthread pthread code, you could leave libc alone. Then, when you linked with libc and libc_r together, the wait4 in libc_r would override the weak aliased wait4 in libc. If you didn't link with libc_r, you'd have your plain old wait4. The bigger problem is that the uthread code needs "two layer" aliasing in order to implement pthread cancellation. > pid_t > wait4(pid_t pid, int *istat, int options, struct rusage * rusage) > { > pid_t ret; > > /* Perform a non-blocking wait4 syscall: */ > while ((ret = _thread_sys_wait4(pid, istat, options | WNOHANG, > rusage)) == 0 && (options & WNOHANG) == 0) { > /* Reset the interrupted operation flag: */ > _thread_run->interrupted = 0; > > /* Schedule the next thread while this one waits: */ > _thread_kern_sched_state(PS_WAIT_WAIT, __FILE__, __LINE__); > > /* Check if this call was interrupted by a signal: */ > if (_thread_run->interrupted) { > errno = EINTR; > ret = -1; > break; > } > } > return (ret); > } > #endif -- 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