This is the mail archive of the
mailing list for the Cygwin XFree86 project.
Re: reset/terminate problems; preventing multiple XWin instances
- From: cygwinx2eran at tromer dot org
- To: cygwin-xfree at cygwin dot com
- Date: Wed, 03 Mar 2004 23:57:22 +0200
- Subject: Re: reset/terminate problems; preventing multiple XWin instances
- Reply-to: cygwin-xfree at cygwin dot com
On 29-02-2004 14:11, Takuma Murakami wrote:
>> As for preventing multiple instances of XWin
> This feature is already implemented in my local tree (not
> port based but mutex based detection).
I see that it's in 4.3.0-50 and working well, but I don't see how the
current implementation addresses the common task I mentioned:
"open an xterm; run XWin first if needed"
If I use a batchfile that always runs XWin and then xterm, from the 2nd
invocation onwards it will produce the error popup reporting a "Fatal
error" and directing me a to log file... Not quite what's needed here.
Perhaps there should be a switch that says "if the display already
exists, exit silently".
But that doesn't solve the case where I want to run additional programs
(say, twm and xeyes) whenever a new display is created -- again a common
scenario, I believe. One way to solve this is to add an option for
checking the presence of an XWin instance on the given display number
and exiting immediately with a corresponding errorcode; a batchfile can
then check for the existance of an XWin instance, and if negative spawn
XWin and related stuff. But this could lead to a race condition if two
batchfiles do the check simultaneously. An alternative is to add an
option for XWin to run some executable iff its startup succeeded.
Yes, I realize this is getting somewhat convoluted, but I think it's an
important and common use case. I'm trying to move a certain large group
of people to Cygwin/X, and the issue of "transparently" invoking
Cygwin/X is one of the two major issues holding things back (the other
one is multiwindow mode performance).
 For extra helpfulness, perhaps you could specify the nature of the
fatal error at a prominent location inside the dialog box and not just
inside the log file?