Re: checkX problems

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Jon TURNEY wrote:
> But why would you fix the timeout problem by doing some horrible
> horrible iteration in the DOS batch script (horrible) (which would
> probably have to busy-wait (also horrible) as there's no sleep command),
> when you can fix checkX, which has the bonus of fixing other uses of it?

I actually wrote a version of this. It IS horrible -- but no need for a
busywait, I used the "ping trick":

C:\windows\system32\ping -n 2 127.0.0.1>nul

"sleeps" for (n-1)==1 seconds.

>> Since more people seem to have this problem (cf. also Olivia's post), I
>> repeat my question (essentially already posed by Ken Brown:
>> http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg19402.html): Why
>> using ``run'' at all? If we really need a wrapper (do we?) wouldn't
>> ``sh'' be a better one?
> 
> I guess we use run for the reason run exists: to hide the console
> window, which otherwise would be shown?

But checkX is compiled as a GUI program, so it really shouldn't need
"run" to hide its (non-existent) console:

$ objdump -p /usr/bin/checkX.exe | grep ^Subsystem
Subsystem               00000002        (Windows GUI)

Now, in startxwin.bat, we actually use:

%RUN% checkX -wait <other args>

run.exe is peculiar. The first argument is the target, and IF the VERY
NEXT argument is "-wait", run "usurps" that argument.  That is, run will
invoke:
    checkX <other args>
and checkX will never see "-wait".  So, what does run.exe do with
"-wait"? It...waits.  run.exe won't exit, until after the inferior does.
 So, if checkX takes 12 seconds to come back, then run will take 12
seconds ... and the entire script is paused until checkX exits.

HOWEVER, since checkX is a GUI program, you SHOULD get the same result
from both of these two commands:

%RUN% checkX -wait <other args>
checkX <other args>

> Perhaps if you look how startxwin.bat is started from the start menu
> shortcut, (as 'run startxwin.bat') you can see why this might be useful?
> 
>> To push this even further: Do we really need two *independent* scripts,
>> ``starxwin.bat'' and ``starxwin.sh''? Why can't the former just delegate
>> to the latter?
> 
> Indeed.  They are useless to me for starting the server and a continual
> source of problems.  I would be quite happy to just delete them
> completely.  :-)

Well, I think the OP is suggesting that one or the other go away, not
both. <g>  However, what is /your/ preferred way of starting the Xserver
from a shortcut, Jon? launching xinit via run?  or do you always start
the server from within an existing shell session?

> Looking forward to reading your patches to address any of these problems.

It shouldn't be too hard to add an option to checkX to make it "retry"
if ECONNREFUSED. This would have to manually track the elapsed time for
each attempt, charging against the specified -t <waittime>. Just look at
run2-0.3.0/lib/checkX.c::try_with_timeout().  Some function signatures
might need to be changed in order to pass opt.retry down to that level,
but it'd be a nice short project for someone.

I'll try to get to this but it'll be a few weeks, unless somebody sends
me a patch sooner.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/