From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22854 invoked by alias); 8 Oct 2004 10:05:48 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 22844 invoked from network); 8 Oct 2004 10:05:46 -0000 Received: from unknown (HELO gnu.wildebeest.org) (82.161.94.186) by sourceware.org with SMTP; 8 Oct 2004 10:05:46 -0000 Received: from slauerhoff.wildebeest.org ([192.168.1.27] ident=mark) by gnu.wildebeest.org with esmtp (Exim 3.35 #1 (Debian)) id 1CFrcX-0001g6-00; Fri, 08 Oct 2004 12:05:05 +0200 Subject: Re: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken From: Mark Wielaard To: Stephen Crawley Cc: Noa Resare , Mauve Discuss , crawley@piglet.dstc.edu.au In-Reply-To: <200410080647.i986l9QQ020343@piglet.dstc.edu.au> References: <200410080647.i986l9QQ020343@piglet.dstc.edu.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pFKvoEIuBfhMyU7CDgVT" Message-Id: <1097229925.1087.10.camel@localhost> Mime-Version: 1.0 Date: Fri, 08 Oct 2004 10:05:00 -0000 X-SW-Source: 2004-q4/txt/msg00003.txt.bz2 --=-pFKvoEIuBfhMyU7CDgVT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 1802 Hi, On Fri, 2004-10-08 at 08:47, Stephen Crawley wrote: > noa@resare.com said: > > Since the test doesn't actually test for anything other than the > > ability to open many files and the extent of that ability isn't > > specified in any spec that I'm aware of I suggest that we remove the > > test.=20 >=20 > Agreed. It should be deleted. >=20 > This testcase previously used to also (indirectly) check that orphaned fi= le > handles were closed by garbage collection finalization. However, this > was done by explicitly calling System.gc(), and thus was even more broken > that the current version of the testcase. As the person that wrote this test let me explain why I wrote it and what I think should be tested. We had a problem with real programs that open lots of files quickly (gjdoc does this for example, a jar tool or a webserver might be another good example) and don't explicitly close these files, but let the file/stream just get garbage collected since the program structure doesn't explicitly define a "owner" for the file/stream object (which isn't that uncommon since that is what you normally do with random allocated objects, long life the garbage collector!). What I think should be tested is whether a program can open lots of files. And that the systems notices that stale file handle resources can be removed so that a program can keep opening files if needed. (As long as there are no large number of life file handles open at the same time.) Since I have seen multiple systems get this wrong in various ways I want to have an explicit test for this situation. It might be that this test does not simulate a real world program correctly, so if there are alternatives I would like to hear them instead of just deleting the test since some systems fail it. Cheers, Mark --=-pFKvoEIuBfhMyU7CDgVT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBZmZkxVhZCJWr9QwRAgWNAJ9Gb7kwpETOIWhGGBgDOS+RafTfSQCfQSk8 xrYSfHuJL3yI5F3kt9sheT8= =zSlZ -----END PGP SIGNATURE----- --=-pFKvoEIuBfhMyU7CDgVT--