Date: Tue, 6 Jul 1999 13:28:37 -0400 (EDT) From: "Brian F. Feldman" <green@FreeBSD.org> To: John Polstra <jdp@polstra.com> Cc: hackers@FreeBSD.org Subject: Re: poll() vs select() Message-ID: <Pine.BSF.4.10.9907061327110.4140-100000@janus.syracuse.net> In-Reply-To: <199907061644.JAA15384@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Jul 1999, John Polstra wrote:
> In article <Pine.BSF.4.10.9907042155090.66085-100000@janus.syracuse.net>,
>
> The application itself has to get involved if it wants to do async
> name lookups, or async anything else, for that matter. Suppose you
> do have an async thread to do hostname lookups as you propose. What
> is the application going to do while that thread is waiting for the
> lookup to complete? It depends on the application, and thus it has
> to be coded into the application. Maybe there's nothing useful the
> application could do until the lookup returns.
>
> I've been told that it works fine to use libc_r and put the name
> lookups into a separate thread. But to take advantage of it, the
> application has to have something useful it wants to do (and can do)
> in the meantime.
It would let the other threads run more while the lookup is occurring.
Wouldn't that be the most natural expectation of it? Or would this
be too hard without kernel-assisted threading?
>
> John
> --
> John Polstra jdp@polstra.com
> John D. Polstra & Co., Inc. Seattle, Washington USA
> "No matter how cynical I get, I just can't keep up." -- Nora Ephron
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
green@FreeBSD.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
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?Pine.BSF.4.10.9907061327110.4140-100000>