From owner-freebsd-hackers Tue Apr 9 11:50:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA02954 for hackers-outgoing; Tue, 9 Apr 1996 11:50:32 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA02947 for ; Tue, 9 Apr 1996 11:50:24 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05594; Tue, 9 Apr 1996 11:38:09 -0700 From: Terry Lambert Message-Id: <199604091838.LAA05594@phaeton.artisoft.com> Subject: Re: freebsd threads To: dsantry@maccs.dcss.McMaster.CA (Douglas Santry) Date: Tue, 9 Apr 1996 11:38:09 -0700 (MST) Cc: hackers@FreeBSD.org In-Reply-To: <199604091442.KAA03295@church.dcss.mcmaster.ca> from "Douglas Santry" at Apr 9, 96 10:42:10 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I don't know who to send this to so I thought the general hackers address > would be a start. I am currently implementing user threads that are managed > by the kernel so multithreading is possible. I am *not* multithreading the > kernel. It will still only allow one active task in the kernel at a time. I > am using syscalls 172-175 and 177-180. If this is a problem please let > me know. I am checking with you folks cuz I thought you may be interested > in including this code in your general distribution one day. Are these > syscalls ok or should I move them? > > PS I can't seem to find the code for libc. I can only find man pages for > libc under /usr/src/lib/libc/sys which I find kinda strange. Where should > I be looking? > > If anybody is interested in what I'm doing send me a note and I'll give more > details. How does this compare to the existing pthreads implementation? If you are trying to turn "blocking system call" into "async system call plus context switch" (what Sun did with LWP in SunOS), may I suggest an alternate approach? Add a field to the sysent structure for each system call to allow you to set a flag for "asyncable", "already async", and "non-asyncable". Then use a different call gate but the same system call code and handle the change in the call gate and sleep/tsleep code. This approach will take a hell of alot less work on your part (you will still need to handle event context and you will probably still need a single multiplex entry call for aiowait/aiocancel, though). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.