classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NIO (Non-block & Scatter/Gather)


From: Mark Wielaard
Subject: Re: NIO (Non-block & Scatter/Gather)
Date: Thu, 12 Jan 2006 11:53:04 +0100

Hi Mike,

On Wed, 2006-01-11 at 22:26 +0000, Michael Barker wrote:
> My name is Mike Barker.  I am interesting in contributing to the GNU
> Classpath project.  As a start I have looked the NIO implemenation with
> regards to Channels (specifically SocketChannel).  

Very cool!

> Attached to this mail is a patch that adds support for configuring a
> socket to be non-blocking and uses readv and writev system calls to
> support native scatter/gather operations.  Native access is through a
> VMChannel.java class.  This class could also be added to other Channel
> types to implement native scatter/gather I/O across the board.
> 
> The patch is not quite complete.  It passes the Mauve tests, but
> requires a more comprehensive set of tests (e.g. testing readv/writev
> and different types of ByteBuffer, direct & mapped).  However if what I
> doing looks reasonably sane, I can continue in order to provide a more
> complete patch.  Comments, criticism, etc. is welcome.

The setup seems good. But I only did a quick scan over the code.
Currently busy preparing 0.20 which will hopefully go out this week.
Will take a deeper look next week.

> Quick question:
> I understand the info on the Wiki around developer tainting, which is OK
> as I have not studied the Java sources.

Great. Please do make sure you understnd the requirements in our Hacking
Guide (more explanation in the development wiki):
http://www.gnu.org/software/classpath/docs/hacking.html#SEC2
http://developer.classpath.org/mediation/ClasspathFirstSteps

I'll sent you the request forms for the FSF paperwork.
We do this step to make sure all contributions are original works and to
make sure that people can be assured that GNU Classpath is and always
will be Free Software because we crossed all our ts and dotted all our
is. (Apologies for the bureaucracy.)

>   What about black-box testing of
> the functionality of the JVM?  Does doing this taint the developer?

Just using the interfaces and replicating the behavior of the public
methods is OK. That is essentially what the mauve test do. And that is
how we make sure we are compatible, which is what our users want.

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]