From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 585 invoked by alias); 19 Apr 2007 14:17:44 -0000 Received: (qmail 513 invoked by uid 22791); 19 Apr 2007 14:17:43 -0000 X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_40,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 19 Apr 2007 15:17:41 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l3JEHbSD015235; Thu, 19 Apr 2007 10:17:37 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l3JEHaHl008561; Thu, 19 Apr 2007 10:17:36 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l3JEHZpC007293; Thu, 19 Apr 2007 10:17:35 -0400 Message-ID: <462779F6.1090000@redhat.com> Date: Thu, 19 Apr 2007 14:32:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: Mark Wielaard CC: frysk Subject: Re: event-loop thread changing References: <462501BB.20608@redhat.com> <1176990008.4491.17.camel@dijkstra.wildebeest.org> In-Reply-To: <1176990008.4491.17.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00089.txt.bz2 Mark, I'm not sure I follow. The calls to .start() I've seen were all intentional: - do some stop/start actions with the event-loop in the current thread - [later] create a separate event-loop thread It is just that with the event-loop handling ptrace, the operation isn't allowed. Instead, either: - create the event-loop thread calling eventLoop.start() before anything else xor - run the event-loop from the main thread always Looking at the second case in more detail, the code was originally more like: class EventLoopRunner extends Thread { run() { eventLoop.run() } waitforloopexit () { convoluted logic here } } new EventLoopRunner(); but I reduced it to eventLoop.start. This actually leads us to a real bug, both the above, and: new Thread(eventLoop).start() are racy. This returns, allowing event-loop calls to be made, before the event-loop is ready to handle such requests. The overriden eventLoop.start() addresses this problem. If code is trying to do a .join() then there is a problem. The one issue I do know is code wanting to get a notification when the event-loop panics - both the HPD and FryskGui do this, we need look at extending event-loop to support this. Andrew Mark Wielaard wrote: > Hi Andrew, > > On Tue, 2007-04-17 at 13:19 -0400, Andrew Cagney wrote: > >> I'm now trying to eliminate that server thread and its overhead by, >> instead, having the event-loop thread handle ptrace calls locally. In >> trying to implement the change I've found that a number of test-cases >> are switching the thread running the event-loop mid-stream. Typically >> this happens with something like: >> >> eventLoop.requestSchedule(); >> eventLoop.run(); >> ...; >> eventLoop.start(); >> >> I've added checks to EventLoop to detect this - right now they complain >> but not too loudly - going forward it will trigger a panic. Even >> without the ptrace issue, changing threads is bad. >> > > While you are cleaning this up you might want to make EventLoop just > implement Runnable and not extend Thread. That way people don't get to > accidentally use things like eventLoop.start() or eventLoop.join() > thinking the can just treat it as an Thread. Seems only the > EventLoopTestBed, fstack and the Coredump/StackTraceActions depend on it > being a separate Thread object. And the last 3 seem to really just want > to know when the eventloop has terminated, not really join() with it as > a Thread. > > Cheers, > > Mark >