Date: Sun, 1 Nov 1998 11:25:06 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Richard Seaman, Jr." <lists@tar.com> Cc: John Birrell <jb@cimlogic.com.au>, "current@freebsd.org" <current@FreeBSD.ORG> Subject: Re: Kernel threading (was Re: Thread Scheduler bug) Message-ID: <Pine.BSF.3.95.981101112220.5087D-100000@current1.whistle.com> In-Reply-To: <199810312126.PAA23692@ns.tar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I disagree slightly with the thought that syscalls can be unwrapped with kernel threads. The thread implementation I've seen discussed before is that where new threads are spawned by the kernel, until a limit is reached, after which user-level threading techniques are used to multiplex userlevel threads over a number of kernel level threads. julian On Sat, 31 Oct 1998, Richard Seaman, Jr. wrote: > On Sun, 1 Nov 1998 07:43:04 +1100 (EST), John Birrell wrote: > > >Richard Seaman, Jr. wrote: > > >Kernel threads should use libpthread and libc, not libc_r. > > Agreed, sort of. I don't use libc_r. If you're going to implement > deferred cancellation points, I think you still need to wrap some > syscalls, so you still need to generate a separate libc somewhere. > The "kernel" syscalls drop into libpthread, in a manner analagous > to what happens in libc_r, but the wrappers are different, and the > syscalls that are wrapped are different. > > >You can't mix > >kernel thread syscalls with user-thread syscalls because the styles are > >incompatible (blocking vs non-blocking). > > Agreed. A pure kernel thread implementation seems much simpler because > you just get rid of all the syscall wrapping that's needed to implement > user thread blocking i/o. Or, am I missing something? > > >You can't mix kernel thread > >scheduling with user-thread scheduling. > > Agreed. In kernel threads the kernel scheduler does all the work. > You can get rid of all the 19 pages of user thread scheduling code. > > >It doesn't sound like you have > >made any attempt to update the user-space knowledge of the running thread. > >As a result you will mix all errno codes and all user-space locking. This > >is a fundamental issue that needs to be designed, not hacked. > > Well, the user-space knowledge of the running thread comes from pthread_self, > which in the case I've implemented this comes from the code John Dyson > provided to the list a while back. errno codes are returned on the > thread stack, if I understand his code. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.981101112220.5087D-100000>