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
>