From owner-freebsd-current Mon Dec 1 17:33:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12133 for current-outgoing; Mon, 1 Dec 1997 17:33:01 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA12128 for ; Mon, 1 Dec 1997 17:32:57 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id SAA29191; Mon, 1 Dec 1997 18:40:17 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd029165; Mon Dec 1 18:40:08 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id SAA28471; Mon, 1 Dec 1997 18:32:08 -0700 (MST) From: Terry Lambert Message-Id: <199712020132.SAA28471@usr07.primenet.com> Subject: Re: FYI: usage of new AIO calls To: toor@dyson.iquest.net (John S. Dyson) Date: Tue, 2 Dec 1997 01:32:08 +0000 (GMT) Cc: current@FreeBSD.ORG In-Reply-To: <199712011926.OAA00376@dyson.iquest.net> from "John S. Dyson" at Dec 1, 97 02:26:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > For fun (and actually as a result of a comment by Justin Gibbs), I have put > together a small program that could maybe be used for streaming tape drives > using the new AIO code. Note that if you try this, it must be used only > on current kernels on/after 19:00 GMT, Dec 1. [ ... ] > errval = aio_suspend(&olist[i], 1, NULL); > errval = aio_error(olist[i]); > rtval = aio_return(olist[i]); > errval = aio_write(olist[i]); > nread = read( fd1, bufaddrs[i], BUFSZ); Some questions... 1) Why did you 'read' instead of 'aio_read'? 2) Why did you define your own interface instead of using the SunOS/Solaris/SVR4/SCO interface: -------------------------------------------------------------- #include int aioread(fd, bufp, bufs, offset, whence, resultp) int fd; char *bufp; int bufs; int offset; int whence; aio_result_t *resultp; int aiowrite(fd, bufp, bufs, offset, whence, resultp) int fd; char *bufp; int bufs; int offset; int whence; aio_result_t *resultp; -------------------------------------------------------------- #include #include aio_result_t *aiowait(timeout) struct timeval *timeout; -------------------------------------------------------------- #include int aiocancel(resultp) aio_result_t *resultp; -------------------------------------------------------------- Is there a reason for this incompatability? You are aware that there exist many programs for which we should like to provide ABI compatability that directly reference these calls, including the library code from the University of Washington paper "User Space Threading And SPARC Register Windows" ... AKA SunOS 4.1.3 liblwp, right? 3) Do you plan on adding the compatability header file and compatability system calls? Not to rain on anyone's parade, but I sort of just assumed that any "AIO" implementation that was implemented as other than a generalized async call gate mechanism (so that a cooperative kernel/user threading scheduler could be built) would be implemented as a compatability API for exising AIO mechanisms, and not some new invention. 8-(. Pretty cleary, the new invention (just like Sun's invention) is less than useful for socket I/O that needs to consider OOB data. Like the Telnet protocol used on the control connection to an FTP server. I like the idea of adding list-based mechanisms, but at the very least, the API consumed by existing software should probably be supported (and probably not as wrappers, both for ABI and for non-list-based performance considerations). For example, can't pthreads from the MIT distribution use aio instead of select() based "readability/writeability" testing for a significant performance win? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.