Date: Sat, 3 Jul 1999 01:01:07 -0400 (EDT) From: "Brian F. Feldman" <green@unixhelp.org> To: Jonathan Lemon <jlemon@americantv.com> Cc: wayne@crb-web.com, hackers@FreeBSD.ORG Subject: Re: poll() vs select() Message-ID: <Pine.BSF.4.10.9907030058240.22384-100000@janus.syracuse.net> In-Reply-To: <199907030427.XAA17423@free.pcs>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> In article <local.mail.freebsd-hackers/Pine.LNX.3.95.990702160538.27513C-100000@crb.crb-web.com> you write:
> >now supports the select() and poll() system calls. My question is really one
> >of usage. Why would one us poll() over select()? Is select eventually going
> >to go away for some reason?
>
> select() as a user-level call will never go away; there is a large base
> of code that uses it.
>
> poll() is faster (it doesn't have to do bit twiddling), and it's interface
> is cleaner (it can report invalid fd's, something select() can't do). As
> its functionality is a superset of select()'s, it is used as the internal
> implementation for select().
Actually, select() doesn't require horrendous amounts of copyin()s, which
poll() does. So have you benchmarked the two? I'd expect select to be faster.
>
> As for new code, use whichever you are comfortable with. Personally, I
> would recommend poll(), since it provides some added functionality over
> select() that makes for easier programming.
poll() is a huge pain to use, which is why I recommend select().
>
> --
> Jonathan
>
>
> 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.9907030058240.22384-100000>