Subject: RE: Process does not respond to signals on read() of win32 handle
From: <[email-masked]>
To: "Harig, Mark A." <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 06 Nov 2002 19:40:00 -0500

If I try /dev/com0 or /dev/com1 etc. then the program core dumps. If I try
/dev/com,
then it behaves exactly like before, no signals are processed.

Thanks
Sanjay

On Wed, 6 Nov 2002 19:30:42 -0500 "Harig, Mark A." <[email-masked]>
wrote:

> Did you pass "/dev/com" or "/dev/com0"?
> 
> (Hmm.  What is this 'redback' you speak of? :)
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > Sent: Wednesday, November 06, 2002 7:09 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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, 
> > [email-masked] 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/