Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
From:	swamp-dog AT ntlworld DOT com (Guy Harrison)
To:	cygwin AT cygwin DOT com
Subject:	Re: cvs cygwin1.dll
Date:	Wed, 18 Sep 2002 18:42:50 GMT
Message-ID:	<3d88c6c1.17117483@smtp.ntlworld.com>
References:	<3d81aa1b DOT 1496411 AT smtp DOT ntlworld DOT com> <20020913125816 DOT GA1030 AT redhat DOT com>
In-Reply-To:	<20020913125816.GA1030@redhat.com>
MIME-Version:	1.0
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id g8IIk9616513

On Fri, 13 Sep 2002 08:58:16 -0400, Christopher Faylor <cgf AT redhat DOT com>
wrote:

>On Fri, Sep 13, 2002 at 09:09:37AM +0000, Guy Harrison wrote:
>>I can't seem to figure out how to set a breakpoint in sigproc.cc without
>>recompiling make with debug. Any hints?
>
>Just attach to the running process and set a breakpoint.
>
>Alternatively, use the "dll" command to load cygwin1.dll and then set
>a breakpoint on a *line number*.

Thanks, the latter helped verify that debugging made the problem go away
- ditto strace. Initially I thought it was a race. Racing certainly
helps trigger it but that isn't the problem.

I can't see a mechanism involving cygthread::stub to cater for the case
where "last man out"+1 ensures "last man out" is running. In all
situations where abnormal behaviour occurs we're left waiting upon a
process that consists of a single suspended cygthread::stub thread.
Others should be able to verify this by bumping up the size of the
cygthread.cc threads[] array up to a silly value then attempt an
intensive configure/make/install with it. Conversely now that I've set
threads[1] there's been no breakages.


Assuming the above gets fixed, coming back to racing, I saw that often
times the suspended thread never even got started by the time it found
itself in control. Might be worth trying cygthread::runner firing
non-suspended threads then let each stub initially stop itself. It's
tempting to suggest taking advantage of windows' dire scheduling with
something like this ...

cygthread::stub()
{
 cur = DropPriorityToMostIdle();
 while (!info->func)	//"volatile"
 ;
 RestorePriority(cur);

 ::CreateEvent();
 while (1) {
   if (!info->func)
     ::ExitThread(0)
   ;

   info->func();
   info->func = 0;
   ::SetEvent();

   cur = DropPriorityToMostIdle();
   while (!info->func)
     //::Sleep
   ;
   RestorePriority(cur);
 }
}


-- 
swamp-dog AT ntlworld DOT com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -