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
X-MimeOLE:	Produced By Microsoft Exchange V6.0.4417.0
content-class:	urn:content-classes:message
MIME-Version:	1.0
Subject:	RE: Process does not respond to signals on read() of win32 handle
Date:	Wed, 6 Nov 2002 19:30:42 -0500
Message-ID:	<BADF3C947A1BD54FBA75C70C241B0B9E76303C@ex02.idirect.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
From:	"Harig, Mark A." <maharig AT idirect DOT net>
To:	<sanjayl AT mindspring DOT com>
Cc:	<cygwin AT cygwin DOT com>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id gA70Usl21548

Did you pass "/dev/com" or "/dev/com0"?

(Hmm.  What is this 'redback' you speak of? :)

> -----Original Message-----
> From: sanjayl AT mindspring DOT com [mailto:sanjayl AT mindspring DOT com]
> Sent: Wednesday, November 06, 2002 7:09 PM
> To: cfg AT redback DOT com
> Cc: cygwin AT cygwin DOT com
> Subject: Re: Process does not respond to signals on read() of win32
> handle
> 
> 
> Christopher,
> 
> thanks for the info. If I pass any "/dev/com" to
> _cygwin_attach_handle_to_fd() it core dumps :-(.
> 
> What is the significance of the name param. Does it create a 
> device node
> within the cygwin layer??
> Can it be any path??  I am guessing from what you said, that 
> if it is any
> random path, it is assumed to be a fast device?
> 
> Thanks for your help
> Sanjay
> 
> On Wed, Nov 06, 2002 at 04:22:18PM -0500, 
> sanjayl AT mindspring DOT com wrote:
> >Hi Mark,
> >
> >I am running Cygwin on Windows 2000. Here is the output of uname -a
> >
> >
> >
> >CYGWIN_NT-5.0 REDBSUNJAY1 1.3.14(0.62/3/2) 2002-10-24 10:48 
> i686 unknown
> >
> >And here is a short program that can reproduce the bug.  I just
> >CreateFile() COM0 and then map it to a cygwin file desciptor.  I then
> >read() on the fd.  At this point the program stops responding to any
> >signals (CTRL-C) etc, until some data shows up on the device 
> to wake up
> >the read.  I just use g++ com.cpp to compile the executable.
> 
> Theoretically, if you pass "/dev/com0" to the 
> "cygwin_attach_handle_to_fd"
> it would work correctly.  If you don't pass the name of a 
> known device to
> cygwin_attach_handle_to_fd it assumes it is a fast device for which no
> special signal handling is necessary.  So, if it blocks, it 
> will not respond
> to signals, as you've discovered.
> 
> 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/
> 
> 

--
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 -