From owner-cvs-lib Sat Mar 7 19:03:49 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA17242 for cvs-lib-outgoing; Sat, 7 Mar 1998 19:03:49 -0800 (PST) (envelope-from owner-cvs-lib) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA17234; Sat, 7 Mar 1998 19:03:42 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id TAA08108; Sat, 7 Mar 1998 19:01:45 -0800 (PST) Message-Id: <199803080301.TAA08108@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: John Birrell cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-lib@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc_r/uthread pthread_private.h uthread_yield.c In-reply-to: Your message of "Sun, 08 Mar 1998 13:57:51 +1100." <199803080257.NAA10467@cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Mar 1998 19:01:44 -0800 From: Mike Smith Sender: owner-cvs-lib@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Mike Smith wrote: > > > Add sched_yield() witch is the draft 10 equivalent of pthread_yield() > > > from draft 4. Move some of the schedule definitions to sched.h which > > > is a POSIX header. > > > > Is this going to conflict with the upcoming sched_yield() syscall? > > No. That will just gets renamed to _thread_sys_sched_yield() (and ignored) > when built into libc_r. Ah. So realtime and libc_r won't mix? (This is the posix4 stuff that Peter Dufault is working on integrating, BTW.) > The syscalls yield, thr_sleep and thr_wakeup all need work (and preferably > renaming to add underscores before their names to keep the user namespace > clean) to provide a POSIX kernel thread implementation. I have a prototype > for this, but currently no way of getting the running thread back to > user-space reliably (my implementation only works 95% of the time 8-(). Ouch. Sounds nasty. Is this an expansion on the alternate signal stack approach, or a different method? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com