Date: Sun, 19 Dec 1999 14:58:21 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? Message-ID: <19991219145821.D317@tar.com> In-Reply-To: <47485.945636009@monkeys.com>; from rfg@monkeys.com on Sun, Dec 19, 1999 at 12:40:09PM -0800 References: <385CEE25.5239137E@newsguy.com> <47485.945636009@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 19, 1999 at 12:40:09PM -0800, Ronald F. Guilmette wrote: > > In message <385CEE25.5239137E@newsguy.com>, > "Daniel C. Sobral" <dcs@newsguy.com> wrote: > >FreeBSD has userland threads. This is faster than kernel threads, but Actually, userland threads *should* be faster, but for lots of things, they aren't in the current implementation. There is discussion about how to improve this in the -arch mailing list. [snip] > o can block on I/O while other threads in the same process continue > to be scheduled. > > Now you are saying that at present, the FreeBSD implementation of threads > has at least the last of these three attributes. That's the first _I've_ > heard of that, but it is certainly encouraging, and it may cause me to > start doing some stuff with threads under FreeBSD. This has been true for a long very time. > I would really be very grateful however if _someone_ would explain to me > the actual low level-mechanics of how this works, i.e. how one thread in > a ``multi-userland-thread'' process can manage to get control and/or a > CPU time slice when and if a different thread within the same process > gets blocked awaiting some I/O completion. It would be easier for you to read the code (see libc_r/uthread). Its very messy. Basically, all i/o syscalls that can block are converted to non-blocking. If the syscall would block, the userland thread scheduler handles the "blocking", by scheduling another thread, and then periodically polling the i/o device to see if its ready. When it is, the original thread can be restarted. This is why the userland thread scheduler is not very swift, and why user thread context switches are a lot slower than kernel thread context switches. Also note that you can try kernel threads using ports/devel/linuxthreads. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991219145821.D317>