Re: rvxt-20050409-1 console problem [SUMMARY]
Charles Wilson wrote:
(2) add the smart hide console code to rxvt-unicode-X and remove the
brute-force hide console code. Otherwise, the Igors of the world will
have the same where'd my console go problem with rxvt-unicode-X.
There is a downside to this. As Brian mentioned run is not going away
-- because without it (e.g. if rxvt[-unicode-X] hides its own console
after-the-fact) you will always get the briefly flashing cmd console.
Not a big deal, but annoying. But, rxvt-unicode-X can't be used with
run if --login (100% CPU suckage). I dug into this, and discovered a
few things:
rxvt-unicode-X has a main event loop that is completely rewritten from
the one in rxvt. So it's not surprising that it behaves somewhat
differently. What's going on in the problematic case (100% CPU usage if
run+urxvt-X+loginShell=true) is that a select() call is always returning
immediately with data waiting -- except that there's not REALLY any
data waiting.
Because run.exe lauches the child process with no console -- not even a
hidden one, actually -- the stdin/stdout/stderr handles are not
initialized. [1] Somewhere -- and I haven't figured out where, yet,
because the obvious place is NOT it -- rxvt-unicode-X is reopening stdin
to /dev/null (well, technically, it's opening file descriptor 0 to the
file /dev/null...it might not be thinking of it in terms of stdin,
per se. dup2() will automatically use the lowest available file
descriptor -- and if 0 [stdin] is available, suddenly you've got stdin
open again.)
Anyway, /dev/null is of course always ready but never actually has any
data. So the event loop never 'hangs out' in the select. Instead, it's
acting like a polling spinlock -- and that's bad.
So, I get the following repeated over and over -- sucking 100% CPU (and
note the second line!).
===
31 447 [main] rxvt 2744 cygwin_select: 7, 0x22EDC0, 0x22EDB8,
0x0, 0x0
52 499 [main] rxvt 2744 dtable::select_read: /dev/null fd 0
49 548 [main] rxvt 2744 dtable::select_read: fd 4
45 593 [main] rxvt 2744 dtable::select_read: /dev/ptmx fd 6
27 620 [main] rxvt 2744 cygwin_select: to NULL, ms
92 712 [main] rxvt 2744 cygwin_select: sel.always_ready 1
24 736 [main] rxvt 2744 select_stuff::cleanup: calling cleanup
routines
20 756 [main] rxvt 2744 socket_cleanup: si 0x0 si-thread 0x0
18 774 [main] rxvt 2744 socket_cleanup: returning
36 810 [main] rxvt 2744 peek_socket: considering handle 0x6D4
23 833 [main] rxvt 2744 peek_socket: adding read fd_set , fd 4
34 867 [main] rxvt 2744 peek_socket: WINSOCK_SELECT returned 0
20 887 [main] rxvt 2744 set_bits: me 0x702AC0, testing fd 0
(/dev/null)
19 906 [main] rxvt 2744 set_bits: ready 1
18 924 [main] rxvt 2744 select_stuff::poll: returning 1
18 942 [main] rxvt 2744 select_stuff::cleanup: calling cleanup
routines
19 961 [main] rxvt 2744 select_stuff::~select_stuff: deleting
select records
671028 [main] rxvt 2744 set_signal_mask: oldmask 0x0, newmask
0x84002, mask_bits 0x0
191047 [main] rxvt 2744 set_signal_mask: not calling
sig_dispatch_pending
211068 [main] rxvt 2744 readv: readv (0, 0x22ED50, 1) blocking,
sigcatchers 3
211089 [main] rxvt 2744 readv: no need to call ready_for_read
201109 [main] rxvt 2744 fhandler_base::read: returning 0, binary
mode
181127 [main] rxvt 2744 readv: 0 = readv (0, 0x22ED50, 1), errno 0
211148 [main] rxvt 2744 set_signal_mask: oldmask 0x84002,
newmask 0x0, mask_bits 0x84002
201168 [main] rxvt 2744 cygwin_select: 7, 0x22EDC0, 0x22EDB8,
0x0, 0x0
===
[1] Here's the important bit from run.exe:
memset (start, 0, sizeof (start));
start.cb = sizeof (start);
start.dwFlags = STARTF_USESHOWWINDOW | STARTF_USESTDHANDLES;
start.wShowWindow = SW_HIDE;
start.hStdInput = GetStdHandle(STD_INPUT_HANDLE);
start.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE);
start.hStdError = GetStdHandle(STD_ERROR_HANDLE);
sec_attrs.nLength = sizeof (sec_attrs);
sec_attrs.lpSecurityDescriptor = NULL;
sec_attrs.bInheritHandle = FALSE;
if (CreateProcess (NULL, cmdline, sec_attrs, NULL, TRUE, 0,
NULL, NULL, start, child))
{
Sure, it's *supposedly* setting start.hStdInput and friends to The Right
Thing, but according to MSDN (in the AllocConsole() description):
GUI applications are initialized without a console. Console
applications are initialized with a console, unless they are created as
detached processes (by calling the CreateProcess function with the
DETACHED_PROCESS flag).
Since run.exe is a GUI app, it has no console at all -- and therefore
GetStdHandle() returns INVALID_HANDLE_VALUE, which isn't a very nice
thing to initialize start.hStdInput and friends to.
But here's the thing: run.exe's job is to launch an application without
a *visible* console.
Re: rvxt-20050409-1 console problem [SUMMARY]
Charles Wilson wrote: I'm leaning toward this solution, in a more generic sense, like: gui-switcher.exe --config=/etc/rxvt-selector.conf It'll go into the checkX package since it'll leverage a lot of the same code. And that's why I need to track down these issues with rxvt-unicode-X+run+loginShell...'cause if they are not solved with run.exe, they'll show up again with gui-switcher.exe. I know this isn't an ideal solution, but have you considered fork()ing and exec()ing 'checkX' and using wait() to get the return code? That would require your app to have checkX installed but would avoid duplicating the code and/or having to library-ize it (i.e. would be faster to implement). OTOH a lib (or static lib) is generally not a bad idea. -- Matthew Hey, buddy, if it's OT, TITTTL! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: rvxt-20050409-1 console problem [SUMMARY]
1. Thanks for taking on the 'rxvt' package. I look forward to the code changes that will make 'man' pages more readable. (3) (a) add a command line option to say force hide console and use that from scripts 2. I do not have any need for the script usage that you described so I am neutral with respect to whether you add this new feature. If you decide to add the feature, I would suggest that you implement the usual three ways of using it: - highest priority: a command-line switch - next priority: an environment variable - lowest priority: the ~/.rxvt configuration file 3. FWIW, here is a font that I found useful. It has worked on various Windows versions (nt/2k/2003/xp) without any additional steps required on my part (i.e., no additional fonts needed to be installed). It is not mentioned in /usr/share/doc/Cygwin/rxvt-20050409.README. If you find it useful, please feel free to add it to the ones listed in that README file. Simply cutpaste the line to your ~/.Xdefaults. It resizes fairly well with Shift-[num +]/Shift-[num -]. rxvt*font: -outline-Courier New-normal-r-normal-normal-20-96-120-120-c-100-iso8859-1 --- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rvxt-20050409-1 console problem [SUMMARY]
Igor Peshansky wrote:
After installing rxvt-20050409-1, starting rxvt from a console bash hides
that console. To reproduce: start a console bash, type rxvt or rxvt
(either way), observe that the bash window goes away (the process is still
running, though). I don't think the cygcheck output is relevant, since
this looks like an rxvt problem (caused by the new code to hide the
console). Chuck, if you can't reproduce this, please let me know and I'll
provide more details.
Nope, don't need to reproduce it -- it's an obvious (now!) effect of the
code. I've got an idea for a solution to this problem I've created, but
first I want to address some misconceptions downthread.
==
(1) Brian Dessent was 99.9% right in this message
(http://cygwin.com/ml/cygwin/2006-05/msg00376.html). 100% if you take
the correction in his immediate followup.
If CYGWIN contains tty (set BEFORE the bash shell is started; e.g. via
the Windows Environment), then you're using ptys. -mwindows apps (like
javaw) can communicate with the console, but only if they like ptys.
Not all of them do (C:\Windows\system32\ftp.exe does not, for example).
If you're using rxvt or ssh, then you're using ptys.
However, if you're using PLAIN OLD CMD.EXE *and* CYGWIN does not contain
tty, THEN, and ONLY then, are you actually using direct console I/O. In
this scenario, -mwindows do not HAVE console I/O, so they cannot
communicate with the spawning console. (unless they use the XP API to
reconnect, as Brian mentioned). Since neither of those two options are
acceptable, -mwindows is not allowed.
==
(2) So, we've had rxvt for years, and run.exe for years, and this combo
has worked just fine. rxvt is a -mconsole app, it can talk to the
spawning console (rxvt --help works) regardless of
cmd.exe/CYGWIN=tty/rxvt/whathaveyou). However, if launched via a
shortcut from the Windows Environment (Start Menu, Desktop, Explorer,
etc), it will create a dummy cmd.exe window -- because it is an
-mconsole app, and that's what they do. [* errm, not really. See ==1==
below]
Well, as one poster suggested, you could create the console window with
!SW_VISIBLE. The problem with that idea, is that by the time you've got
control the console has already been created! So, what you do, is
OPTIONALLY -- e.g. when you don't care about interaction with the
spawning console, like if you're double-clicking a windows shortcut --
use a helper application that is compiled -mwindows. It can then create
a hidden (!SW_VISIBLE) console, and pass that console to the client
application by launching the client directly using the WindowsAPI
CreateProcess, instead of cygwin's spawn/exec/family.
Well, that's exactly what run.exe does.
Another alterative is for rxvt to hide the console after it is launched
(but this leads to a briefly flashing cmd.exe window). [*] ==1==
=
So, until now, if you're (manually) launching rxvt from a console --
whether an rxvt/xterm one, a cmd.exe+CYGWIN=tty one, or a
cmd.exe+CYGWIN=notty one -- then you simply call rxvt.exe directly. It
just works. And your console -- even if it was a cmd+CYGWIN=notty one
-- did not disappear on you. I broke this when cmd+CYGWIN=notty. Oops.
If you wanted to launch rxvt from the Windows Environment, you used
run.exe to launch the rxvt indirectly. That just works. (There is no
cmd.exe window, not even a briefly flashing one).
[*] The following was news to me, but I've verified it and dug into the
code to figure out why. Mark Harig was correct here:
http://cygwin.com/ml/cygwin/2006-05/msg00386.html
It turns out that if you launch rxvt directly from the windows
environment, it -- even before I messed with it -- will follow the
procedure above at ==1==. It turns out that the libW11 wrapper code in
rxvt-2.7.10-6 already has a variant of the hide_console code. It
differs from the new code I added in that it has some kind of test to
see if its associated console was spawned in response to its own launch,
or if it pre-existed. In the former case (e.g. you double clicked a
shortcut and Windows launched the process with an associated console) it
would hide the console -- after the obligatory brief flash. In the
latter case -- the console was already there, and you manually typed
'rxvt' or whatever -- then it would NOT hide the console. Pretty slick:
hConsole = CreateFile( CONOUT$,
GENERIC_WRITE | GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE, sa,
OPEN_EXISTING, 0, 0 );
if (GetConsoleScreenBufferInfo(hConsole,buffInfo)
buffInfo.dwCursorPosition.X==0
buffInfo.dwCursorPosition.Y==0)
{
... only then, do we hide the console ...
}
=
So why did I bother? Well, 'cause (a) I didn't know about the above; I
always got cmd.exe boxes because I always launched rxvt via a script,
not directly, and (b) I *wanted* to be able to launch rxvt via windows
shortcut to a script and STILL be
