From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18430 invoked by alias); 8 Feb 2008 14:27:06 -0000 Received: (qmail 18304 invoked by uid 48); 8 Feb 2008 14:26:23 -0000 Date: Fri, 08 Feb 2008 14:27:00 -0000 Message-ID: <20080208142623.18303.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jvdelisle at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-02/txt/msg00952.txt.bz2 ------- Comment #25 from jvdelisle at gcc dot gnu dot org 2008-02-08 14:26 ------- Reply to comment #23. With external units we have a treap structure which holds pointers to the unit structures so that we reuse them as needed The treap is searched first for an existing unit and returns that if it exists. This keys off of the unit number. This one handle per unit. With internal units we do not have a unit number to key off. I could use the address of the string itself. I have not pursued that avebue yet because it is not the simplest approach. I have successfully tested a patch that uses a single static unit structure for all internal units, relying on the locking mechanism to assure that it is used only by one operation at a time. It works great and improves performance by avoiding the memory allocation overhead. It uses at most only one handle. Unfortunately, it breaks write_recursive.f90. Recursive I/O is permitted on internal units in F2003. Reply to comment #24 The patch from Danny adds a new function to gthr-win32.c that does a CloseHandle. I will be testing this approach soon. Regardless, I am leaning toward not locking the internal units because of some performance gain and the need to retain recursive IO. I will do some comparative tests between the CloseHandle approach and the no lock approach before proposing to the list the final patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063