Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Thu, 26 Sep 2002 10:42:56 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: cvs cygwin1.dll Message-ID: <20020926144256.GD8605@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <3d81aa1b DOT 1496411 AT smtp DOT ntlworld DOT com> <20020913125816 DOT GA1030 AT redhat DOT com> <3d88c6c1 DOT 17117483 AT smtp DOT ntlworld DOT com> <20020918193553 DOT GA9328 AT redhat DOT com> <3d8bf2b5 DOT 1540735 AT smtp DOT ntlworld DOT com> <20020920155657 DOT GH24740 AT redhat DOT com> <3d90daeb DOT 24161151 AT smtp DOT ntlworld DOT com> <20020922164054 DOT GB25597 AT redhat DOT com> <3d938f4b DOT 332481943 AT smtp DOT ntlworld DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3d938f4b.332481943@smtp.ntlworld.com> User-Agent: Mutt/1.4i On Thu, Sep 26, 2002 at 05:20:53AM +0000, Guy Harrison wrote: >On Sun, 22 Sep 2002 12:40:54 -0400, Christopher Faylor >wrote: >>>>I don't think it has anything to do with suspended threads. You can >>>>certainly verify this by adding code to kill the threads specifically, >>>>though, and see what happens. >>> >>>I did. I declared threads[1]. All the work gets shoved onto >>>cygthread::simplestub which neither suspends nor stays resident. >> >>Not the same thing at all. > >I don't follow the implication. Had the fault been in info->func() then >::simplestub would have done same. It didn't. Explicitly terminating the >thread would bypass the dll detach/race thereby imposing a much greater >impact on code behaviour. I think I've reached the limit of my wanting to explain things. I've tried. I'm not interested in pursuing things further. >>>Our hung process is definately suspended. >> >>Not necessarily. I see nothing in the above which would disprove the >>theory that this is the problem which I raised in cygwin-developers. Of >>course, I am not 100% sure that I understand the above data. > >No worries. One big multi meg file or [ahem] 16,000+ tiny ones. Didn't >think I ought to post that. The main point is (non-static) >cygthread::SD_count is explicitly initialised by me. I've often seen the >later members of the threads[] array zero. > >I've looked into that aspect a bit more. Other perfectly functional >processes are having this occur. For instance, the "sig" thread isn't >always getting allocated into threads[NTHREADS-1] but earlier up and >threads["sig"+1]..threads[NTHREADS-1] are all zero. Nothing wrong with this. It's to be expected. >>I'm not going to devote too much time to studying it since there is an >>obvious problem in the cygwin DLL now and you haven't, AFAICT, addressed >>that. This makes your analysis suspect until you generate a version of >>the DLL without the already known problem. > >If you don't think threads[1] served any useful purpose then so be it. I don't think that completely changing the thread allocation serves any useful purpose. I've already mentioned what I think the problem is. It is the fact that there are many threads available to tickle the previously identified deadlock. >>However, if you want to provide an actual analysis of how the thread >>could be in a suspended state with someone waiting for it, that would be >>welcome. > >If I knew unix I probably could - it's preventing me understanding >crucial aspects of the cygwin dll. Nevertheless, methinks we're both >correct. I've been thinking along these lines... Why are you mentioning UNIX? This is all Windows code. Nevermind. You don't have to answer that. This conversation is becoming Derbyshire-esq. Let me ask a simple question: Do you still have problems with the current version of cvs? Just a yes or no answer please. No descents into code. No tweaking values that you think are causing problems. No colloquial observations. Just "yes, it works" or "no, it still hangs". cgf -- 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/