Mail Archives: cygwin/2002/09/26/10:42:44
On Thu, Sep 26, 2002 at 05:20:53AM +0000, Guy Harrison wrote:
>On Sun, 22 Sep 2002 12:40:54 -0400, Christopher Faylor <cgf AT redhat DOT com>
>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/
- Raw text -