Date: Sun, 19 Dec 1999 13:21:15 -0800 From: "Ronald F. Guilmette" <rfg@monkeys.com> To: hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? Message-ID: <47931.945638475@monkeys.com> In-Reply-To: Your message of Sun, 19 Dec 1999 14:58:21 -0600. <19991219145821.D317@tar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <19991219145821.D317@tar.com>, "Richard Seaman, Jr." <dick@tar.com> wrote: >> 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. OK. That is a clear and adequate explanation. Thank you. I'm not at all sure that I like the idea of something intercepting my syscalls and rewriting them for me, but I understand why it is being done, and (now) I understand how the current ``userland threads'' stuff works. >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. Yes. It sounds to me like each and every time there is a thread context switch, some code in the library may have to execute a (perhaps enormous) call to select() or else to poll(). Yes? (Please don't tell me this is all implemented with asynchronous I/O completion signals. Yecch. That would be awfully slow I think.) >Also note that you can try kernel threads using ports/devel/linuxthreads. I'm in no big hurry. I'll wait for the freebsdthreads. 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?47931.945638475>