Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 209.85.220.219 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=v4j+Nq6DBoypC5R1oID2Y7VN6vPTL7r2fytqFBMnR/jEBc2Qrg0i1cEorllNfU6Qec
         tSJF8q+JRF2oYWXPH9J5fFLHkmqmsTz3qSDwvHo9qSOWJVisuEL7StlQqc8SLmuYU/qm
         qvTFBBc+STBqelGHiImZDnbPGu6IN2JU+JbYU=
Message-ID: <4AC08C3F.8070501@gmail.com>
Date: Mon, 28 Sep 2009 11:13:19 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [jira] Created: (HARMONY-6328) [classlib][nio] optimize
 SocketChannel.write(ByteBuffer[],
 int, int) by writev
References: <290644005.1251857072710.JavaMail.jira@brutus>
 <4A9F8871.4020605@gmail.com> <4A9F9976.7010003@gmail.com>
 <4A9FA881.5020402@gmail.com> <4A9FB1A9.3060803@gmail.com>
 <4AA4C556.3080808@gmail.com> <4AAE6786.4020809@gmail.com>
 <4AAF0963.7030109@gmail.com> <4AAF4B66.5070608@gmail.com>
 <4AAF5592.30402@gmail.com> <4AB0D553.2010100@gmail.com>
 <4AB33D8A.8060206@gmail.com> <4ABA025C.5000309@gmail.com>
 <4ABAFE18.3070802@gmail.com> <4ABB43EF.7080902@gmail.com>
 <4AC0491B.7040605@gmail.com>
In-Reply-To: <4AC0491B.7040605@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28/Sep/2009 06:26, Regis wrote:
> It's a little sad it will break VME. I thought two ways to fix this:
> 
> 1. add new parameter long[] to writev, which contains native address of
> direct buffer, but the parameters will be a little long.
> 
> 2. wrap native address to Long which can be filled in Object[], but this
> may need reflections to get each value of Long.
> 
> Both of them are not so good....

I think we should just raise a bug report to fix the VME.

The exception raised was confusing though,

java.net.SocketException: (10038) An operation was attempted on
something that is not a socket.

Perhaps we do need some more error checking in the native code to cover
these cases so it reports an internal error or something.  It might also
be worth refactoring the code so that the majority is shared, with just
the OS calls moved out to the platform specific directories.

Regards,
Tim