Date: Tue, 15 Jul 2003 04:18:23 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Petri Helenius <pete@he.iki.fi> Cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement Message-ID: <3F13E2FF.60CC7107@mindspring.com> References: <007601c3467b$5f20e960$020aa8c0@aims.private> <004d01c348ae$583084f0$812a40c1@PETEX31> <3F12EF5A.71249E4D@mindspring.com> <16146.65087.69689.594109@emerger.yogotech.com> <3F13B1B4.8765B8F3@mindspring.com> <049201c34aab$9361d070$812a40c1@PETEX31> <3F13D8EC.8899DA42@mindspring.com> <04fa01c34abf$f672e640$812a40c1@PETEX31>
next in thread | previous in thread | raw e-mail | index | archive | help
Petri Helenius wrote: > >The general answer is "kqueue is your friend". 8-). > = > >One thing that is very helpful to do is to seperate out the flags > >and hint arguments to KNOTE(), and then pass the user void argument > >through to the knote() code. Doing this is very handy, besides > >enabling you to raise maxproc higher than the point where it > >collides with the hints bits, I mean. > = > My large fd_set argument was actually targeted towards user space > processes using existing interfaces. Where the viable options seem to > have large select=B4s and do work based by spinning the descriptor set > or have a thread block on the read on the descriptor. I understood that; but kqueue has been around in FreeBSD as an existing interface for longer than libthr or libkse. By rights, it's a much more "existing interface" than threads are. 8-). It's also the same in FreeBSD, OpenBSD, and MacOS X. I don't know if NetBSD has it or not; they don't have the man page up yet, if they do. You could also use poll(2), which gets around many of the major complaints about select(2). Actually, select(2) is an excellent example of an interface that's going to be a holy terror to make thread safe against the close(2) race. Basically, it will need to hold a reference for the entire fd table during the select, and it will have to deal with the possibility of another thread closing and then reopening a given individual descriptor after the first pass through selscan(), but before the second pass. Otherwise it's going to be able to return false positives to user space, and potentially cause a blocking call to be made which will simply hang the worker thread making the call. Enough of those, with a set of worker threads that's smaller than the total number of open fd's, and you're server becomes totally unresponsive to further requests because all your worker threads are wedged. Short of non-blocking I/O, the only thing you could do is deal with implementing the Sun-style cancellation-on-close. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F13E2FF.60CC7107>