This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about tty.cc


On Wed, May 22, 2002 at 10:27:34PM +0100, Chris January wrote:
>
>> >I've tracked down the "dup(/dev) failed" on startup error to the
>following
>> >section of code in tty.cc :
>> >
>> >      char buf[40];
>> >
>> >      __small_sprintf (buf, "cygwin.find.console.%d", myself->pid);
>> >      SetConsoleTitle (buf);
>> >      Sleep (40);
>> >      console = FindWindow (NULL, buf);
>> >      SetConsoleTitle (oldtitle);
>> >      Sleep (40);
>> >      ReleaseMutex (title_mutex);
>> >      if (console == NULL)
>> > {
>> >   termios_printf ("Can't find console window");
>> >   return -1;
>> > }
>> >
>> >Can anyone tell me what the Sleep (40) lines are there for? If they are
>> >there to give the console window time to appear, may I suggest the delay
>is
>>
>> You could suggest that but you'd need a lot more justification.  The code
>> in question is many years old.
>>
>> It's not obvious to me how this translates into an "unable to dup" error.
>No - it wasn't obvious for me, that's why it took so long to track down...
>:-)
>The short story is the dup error always occurs when the "Can't find console
>window" error is generated.
>The long story is that in these circumstances the window takes longer than
>usual to appear, hence FindWindow returns NULL, hence allocate_tty
>returns -1, hence attach_tty returns -1, hence myself->ctty gets set to -1,
>hence in get_devn() in path.cc, the macro real_tty_attached returns false,
>and because myself.ctyy < 0, devn gets set to FH_BAD.
>Hence, when dtable::init_std_file_from_handle() calls
>build_fhandler_from_name which calls path_conv::check, path_conv::check sees
>the FH_BAD returned from get_devn and tries to open C:\Cygwin\dev\tty which
>fails.
>This means a fhandler gets built with the incorrect win32 filename
>(C:\Cygwin\dev\tty instead of \dev\tty1) and the incorrect fhandler type
>(FH_DISK instead of FH_TTYS). When dup is called, build_fhandler is called
>to build the new fhandler and then the dup method of the old fhandler is
>called. However in this case fhandler_base::dup gets called because the
>fhandler is of the wrong type, rather than one of the dup methods in
>fhandler_tty.cc. Because fhandler_base::dup doesn't understand how to
>duplicate tty handles correctly, the method fails and the error I see on the
>screen is the result.

Ah.  Well *now* it's obvious.  Thanks for the explanation.  You obviously
had a "fun" time debugging this.

I wonder if, these days, there are any better ways of doing what this
code is doing.  As I said, this code has been this way for years.
Increasing the timeout is going to have a negative effect on cygwin tty
programs.

Wait.  Hmm.  This is only going to be a problem for programs run directly
via a windows console, right?  It shouldn't be a problem for a child of
bash since it is inheriting the tty handle explicitly.

So, a slowdown should only be in an initial cygwin process.  Is this what
you're seeing?

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]