From owner-freebsd-current Tue Apr 8 10:23:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA19076 for current-outgoing; Tue, 8 Apr 1997 10:23:22 -0700 (PDT) Received: from unique.usn.blaze.net.au (unique.usn.blaze.net.au [203.17.53.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA19060 for ; Tue, 8 Apr 1997 10:23:16 -0700 (PDT) Received: (from davidn@localhost) by unique.usn.blaze.net.au (8.8.5/8.8.5) id DAA02132; Wed, 9 Apr 1997 03:23:04 +1000 (EST) Message-ID: <19970409032303.34151@usn.blaze.net.au> Date: Wed, 9 Apr 1997 03:23:03 +1000 From: David Nugent To: Peter Wemm Cc: freebsd-current@freebsd.org Subject: Re: POLL & the Single FreeBSD'r References: <199704030142.BAA04433@netfl15a.devetir.qld.gov.au> <860439710.357888@haywire.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61 In-Reply-To: <860439710.357888@haywire.DIALix.COM>; from Peter Wemm on Apr 04, 1997 at 07:01:50PM Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I implemented an openbsd-style implementation of poll() some time ago > but it was mixed up in the middle of the upages stuff so it lot left. > Since then, NetBSD have done a much better implementation, I'm very tempted > to back out what I've done and start from scratch while looking at the > NetBSD method. Basically, OpenBSD implemented poll() as an alternative > interface to the select hooks in the kernel which means that poll() is > limited to what select() can test for. NetBSD did it a lot better, by > replacing the select hooks by poll hooks, and updating both front-ends to > use the new poll backend. The main difference is that under NetBSD, you > can poll for (say) ugent data on a socket as opposed to merely "readable". Interesting. Does "urgent data" include, say, an {m,c,a}time change on a file descriptor? If not, could it be implemented? I'm guessting that "urgent data" in this context has the same meaning with a socket with respect to tcp/ip transactions (ie. OOB data), but the hook for poll() I'm suggesting would be perfect for a process that sits and waits for updates or accesses to a disk file. Processes that currently do that have to either use alarm() or call select() with a timeout, and both are fairly sloppy in terms of virtual memory usage. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/