Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Sun, 8 Sep 2002 15:35:59 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: hang in sig_wait waiting for debug lock
Message-ID: <20020908193559.GA7506@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <7710998905 DOT 20020828173811 AT logos-m DOT ru> <20020905153320 DOT GC16827 AT redhat DOT com> <591948241 DOT 20020906185459 AT logos-m DOT ru> <20020906151713 DOT GC21699 AT redhat DOT com> <1176882135 DOT 20020906201713 AT logos-m DOT ru> <20020906210506 DOT GB26002 AT redhat DOT com> <195826558 DOT 20020908204151 AT logos-m DOT ru> <20020908170046 DOT GB7279 AT redhat DOT com> <1615258000 DOT 20020908215542 AT logos-m DOT ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1615258000.20020908215542@logos-m.ru>
User-Agent: Mutt/1.4i

On Sun, Sep 08, 2002 at 09:55:42PM +0400, egor duda wrote:
>Hi!
>
>Sunday, 08 September, 2002 Christopher Faylor cgf AT redhat DOT com wrote:
>
>CF> If you don't want to understand what's going on then that is perfectly
>CF> fine.  However, please don't just assume that if turning on an ifdef
>CF> causes a problem to apparently go away that you've done anything more
>CF> than add an additional delay to cygwin or moved something to a different
>CF> memory location or something.
>
>I'm doing my best to understand how things work. And i concluded that
>for handle protection to work right it's essential to update the list
>whenever we call DuplicateHandle() and replace some handle with its
>duplicate. Maybe i'm wrong here, please correct me if so.

You're not wrong, but that is precisely what is *not* happening when
you turn on the conditional.  There are other DuplicateHandles that
do not call ProtectHandle AFAIK, now, handles from the fd table should
not be put in the protected handle list.  As I said, it is too hard
to get it right.

Hmm.  Maybe ttys are still being put there and that's what you're seeing.
Yep.  That's possible.  Maybe removing these:

  set_io_handle (from_master_local);	// This one
  ProtectHandle1INH (from_master_local, from_pty);
  set_output_handle (to_master_local);
  ProtectHandle1INH (to_master_local, to_pty);	// and this one

would make things better.  I've checked in a patch.

cgf