From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25558 invoked by alias); 25 Sep 2006 18:42:16 -0000 Received: (qmail 25548 invoked by uid 22791); 25 Sep 2006 18:42:14 -0000 X-Spam-Check-By: sourceware.org Received: from mail.cruzio.com (HELO mail.cruzio.com) (63.249.95.37) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 25 Sep 2006 18:42:12 +0000 Received: from [172.100.50.5] (unknown.Level3.net [64.154.219.132] (may be forged)) by mail.cruzio.com with ESMTP id k8PIg9ws003810 for ; Mon, 25 Sep 2006 11:42:10 -0700 (PDT) Message-ID: <451822FB.8080109@gnu.org> Date: Mon, 25 Sep 2006 18:42:00 -0000 From: Casey Marshall User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: mauve-discuss@sourceware.org Subject: multidirectbufferIO and multibufferIO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact mauve-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sourceware.org X-SW-Source: 2006-q3/txt/msg00033.txt.bz2 These two tests, in gnu.testlet.java.nio.channels.FileChannel, look a bit bogus to me. They test if FileChannel artificially limits the number of buffers processed in scattering/gathering read/write to 16, which is definitely the case if the underlying implementation uses readv and writev, but this limit isn't required otherwise (at least, there is no mention of any limit in the JDK docs). I don't see that much point in using readv/writev for file I/O, anyway, especially because there do seem to be bugs in our implementation of it. And at any rate, there's no guarantee that on some other system there would be any limit like this, or if there is, that it would be the same as it is on POSIXy systems.