Re: reset/terminate problems; preventing multiple XWin instance

Re: reset/terminate problems; preventing multiple XWin instance

[cygwinx2eran]

On 2004-03-04 13:12, Alexander Gottwald wrote:

> if ! xdpyinfo >/dev/null 2>&1; then

Cygwin's xdpyinfo waits for 6 second before giving up. A couple of days
ago I posted an alternative solution using netstat, which doesn't have
this delay. Both suffer from race conditions, which are quite likely to
occur in practice -- say, a user clicks his "Cygwin xterm" icon twice in
succession to open two xterms, and as a result gets two XWin instances.

  Eran

Re: reset/terminate problems; preventing multiple XWin instance

[Harold L Hunt II]

I actually have a fairly long laundry list of things that I am going to 
be doing for this "open a unique display number problem".  One of them 
is to add some options for specifying what to do if a particular display 
cannot be opened (-display-or-die), others either let you specify 
whether to assign display 5 (-auto-display-reuse) if 1-4 and 6-10 were 
used or let you specify to assign display 11 (-auto-display-highest) in 
that same case.

I guess the next thing we need then is a way to have the just-started 
XWin process report the display number that it got.  I am thinking of 
several ways to do this, but I haven't stumbled across the optimal 
solution yet.

By the way, the way that I am a proposing to solve the display 
assignment problem should fix cases where only Cygwin/X is being used 
without race conditions (ideally), but I am going to allow for race 
conditions when other X Servers are also being used on the same machine, 
since there doesn't seem to be a uniform way to inform them that certain 
displays are in use already, nor is there an atomic way to decide to use 
a display number and lock it before any random process could also try to 
open that port (at least not that I can think of).

All in all, we will be a heck of a lot better off than we are now.

Harold

cygwinx2eran@tromer.org wrote:
> On 2004-03-04 13:12, Alexander Gottwald wrote:
> 
> 
>>if ! xdpyinfo >/dev/null 2>&1; then
> 
> 
> Cygwin's xdpyinfo waits for 6 second before giving up. A couple of days
> ago I posted an alternative solution using netstat, which doesn't have
> this delay. Both suffer from race conditions, which are quite likely to
> occur in practice -- say, a user clicks his "Cygwin xterm" icon twice in
> succession to open two xterms, and as a result gets two XWin instances.
> 
>   Eran
> 

Re: reset/terminate problems; preventing multiple XWin instance

[cygwinx2eran]

On 2004-03-04 18:02, Takuma Murakami wrote:

> > Perhaps there should be a switch that says "if the display already
> > exists, exit silently".
> I agree.  We should have an option like "-silent" or "-quiet".

That's not quite it -- I want to ignore a "display already exists"
error, but if some other fatal error prevents XWin from loading I want
to know about it (say, via the dialog box).


> Let's suppose Cygwin/X has -silent option as above: then I
> think startxwin.bat with -silent option is sufficient for your
> purpose.  It will start a server (which silently fails if there
> is the other) and then start some favorite applications.

This would spawn new instances of my favorite applications every time I
open an xterm. Not a pretty sight.

  Eran

Re: reset/terminate problems; preventing multiple XWin instance

[Alexander Gottwald]

On Thu, 4 Mar 2004 cygwinx2eran@tromer.org wrote:

> On 2004-03-04 18:02, Takuma Murakami wrote:
> 
> > > Perhaps there should be a switch that says "if the display already
> > > exists, exit silently".
> > I agree.  We should have an option like "-silent" or "-quiet".
> 
> That's not quite it -- I want to ignore a "display already exists"
> error, but if some other fatal error prevents XWin from loading I want
> to know about it (say, via the dialog box).

The do something like this:

export DISPLAY=:0
if ! xdpyinfo >/dev/null 2>&1; then
	XWin $DISPLAY $options
fi
xterm

bye
	ago
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723
 Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004
 http://www.tu-chemnitz.de/linux/tag