Return-Path: Delivered-To: apmail-harmony-commits-archive@www.apache.org Received: (qmail 87327 invoked from network); 27 Nov 2006 16:09:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Nov 2006 16:09:46 -0000 Received: (qmail 61900 invoked by uid 500); 27 Nov 2006 16:09:54 -0000 Delivered-To: apmail-harmony-commits-archive@harmony.apache.org Received: (qmail 61887 invoked by uid 500); 27 Nov 2006 16:09:54 -0000 Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list commits@harmony.apache.org Received: (qmail 61878 invoked by uid 99); 27 Nov 2006 16:09:54 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Nov 2006 08:09:54 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Nov 2006 08:09:44 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id AF6097142F9 for ; Mon, 27 Nov 2006 08:09:22 -0800 (PST) Message-ID: <23754136.1164643762714.JavaMail.jira@brutus> Date: Mon, 27 Nov 2006 08:09:22 -0800 (PST) From: "Nikolay Kuznetsov (JIRA)" To: commits@harmony.apache.org Subject: [jira] Commented: (HARMONY-2219) [drlvm][thread] fix Thread.start() waiting to prevent losing interruption MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ http://issues.apache.org/jira/browse/HARMONY-2219?page=comments#action_12453633 ] Nikolay Kuznetsov commented on HARMONY-2219: -------------------------------------------- Salikh, here is my answer to your question from 1789: > By the way, why we have a waiting loop in Thread.start() at all? Spec does not mandate it. -- I think I would file a separate JIRA to remove this loop. The spec for Thread.start() method says that: "!!!!The result is that two threads are running concurrently!!!!!: the current thread (which returns from the call to the start method) and the other thread (which executes its run method)." It seems to me that this means that after return from the start method both threads should be alive and running, thus synchronization required to wait until child thread run method was called. The right method to implement this in _java_(synchronization on native side is also possible) is to put lock.wait() method into while loop on isAlive condition, to avoid spurious wake-ups and provide expected behavior in any case. Also, interrupting waiting on start methos thread may cause InterruptedException which is not expected from the start method, but just ignoring it is also incorrect, because it may turn into lost interruption. Thus forwarding interrupted status seems to be easiest and correct solution for java style start method synchronization. Thank you. Nik. > [drlvm][thread] fix Thread.start() waiting to prevent losing interruption > ------------------------------------------------------------------------- > > Key: HARMONY-2219 > URL: http://issues.apache.org/jira/browse/HARMONY-2219 > Project: Harmony > Issue Type: Sub-task > Reporter: Salikh Zakirov > Attachments: fix-thread-start.patch > > > This is a splitted out part of H-1789.patch from HARMONY-1789, originally posted by Nikolay Kuznetsov. > fix-thread-start.patch fixes Thread.start() to remember interrupted status if interruptions occur while it waits for the other thread to start, > and restore interrupted status before returning. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira