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/
