From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26834 invoked by alias); 25 Nov 2005 19:10:07 -0000 Received: (qmail 26810 invoked by uid 48); 25 Nov 2005 19:10:06 -0000 Date: Fri, 25 Nov 2005 19:10:00 -0000 Message-ID: <20051125191006.26808.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/15430] Cannot interrupt blocking I/O calls with close() In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "guilhem at kaffe dot org" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2005-q4/txt/msg00407.txt.bz2 List-Id: ------- Comment #11 from guilhem at kaffe dot org 2005-11-25 19:10 ------- I feel a potential race condition in this patch. What happens in that case ? thread 2: => PlainSocketImpl.accept => enters _Jv_select thread 1: => shutdown socket => close socket thread 3: => create another socket which occurs to have the same fd. thread 2: => select wakes up => we call accept with the old fd thread 1: => set native_fd to -1 I expect this scheme may be a flaw and it is not forbidden by the current code. A simple fix would be to add a synchronization lock before accepting the connection. Wrong ? -- guilhem at kaffe dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |guilhem at kaffe dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430