From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12124 invoked by alias); 28 Jul 2006 22:06:28 -0000 Received: (qmail 11981 invoked by uid 48); 28 Jul 2006 22:06:21 -0000 Date: Fri, 28 Jul 2006 22:06:00 -0000 Message-ID: <20060728220621.11980.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/23682] gnu.java.nio.SelectorImpl.select(long) throws ArrayIndexOutOfBoundsException In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "tromey at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-07/txt/msg02205.txt.bz2 List-Id: ------- Comment #5 from tromey at gcc dot gnu dot org 2006-07-28 22:06 ------- I have a patch I'm testing. This code in classpath looks quite bad :( I fixed this problem by adding synchronization. However, really very little synchronization should be needed. Instead we could be doing something like building a data structure for poll() ahead of time and tracking changes to the selection keys more directly; I think this would yield better performance. Right now we do multiple allocations for every select operation. Also I suspect that using select(2) instead of poll(2) is bad for applications making large numbers of connections. select has built-in limits on the the number of file descriptors it can use. Finally. our code to select without waiting actually will wait for up to 1ms. This is fixable as well, it looks like the original author just did it the "simple" way for convenience of writing a single native method. -- tromey at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-05 21:38:39 |2006-07-28 22:06:20 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23682