Date: Tue, 15 Jul 2003 13:58:01 +0300 From: "Petri Helenius" <pete@he.iki.fi> To: "Terry Lambert" <tlambert2@mindspring.com> Cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement Message-ID: <04fa01c34abf$f672e640$812a40c1@PETEX31> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
>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´s and do work based by spinning the descriptor set or have a thread block on the read on the descriptor. Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?04fa01c34abf$f672e640$812a40c1>