RE: xwinclip re selection polling

["Harold Hunt" <huntharo at msu dot edu>]

> -----Original Message-----
> From: cygwin-xfree-owner@cygwin.com
> [mailto:cygwin-xfree-owner@cygwin.com]On Behalf Of Jehan
> Sent: Thursday, August 29, 2002 5:59 PM
> To: cygwin-xfree@cygwin.com
> Subject: Re: xwinclip re selection polling
>
>
> Again, I don't know much about X so I'm going to talk blind here....
>

That's okay, but a lot of these things require a strict reading of the specs
in order to understand what is going on.

> Harold L Hunt II wrote:
> > As far as integrating xwinclip into XWin.exe - Chris would be stuck by
> > the same problem that I am: that the process hosting the xwinclip X
> > client connection gets killed when X shuts down or resets and
> the client
> > connection is still open.
> >
> > I have searched for months and months for a way to receive a definite
> > signal that the X server is about to shutdown.
>
> ... XWin is the X server so if xwinclip is part of XWin, then it knows
> that the server is shuting down/reseting because XWin is shuting
> down/reseting, doesn't it?
>

Ironically, no, there is no interface for the ddx (device-dependent X, which
is stored in xc/programs/Xserver/hw/xwin for Cygwin/XFree86) portion of the
X Server to receive notification that it is about to be reset.  GiveUp is
only called during the shutdown process (not during resets) and I do not
remember if it is called before or after all clients are killed.  However,
the shutdown process doesn't matter if we can't handle the reset process, so
we will have to fix the reset process before we even worry about the
shutdown process.

> Also, I thought that the use of select() in test04 was to avoid problem
> with disconnection.
> test05 changelog says that there is still a problem with GiveUp. But I
> guess that GiveUp ends up calling ddxGiveUp. Maybe this ddxGiveUp could
> be useful (like to close the X client connection if it's not too late to
> do it)
>

Well, yes, using select () was necessary to make sure that Windows messages
don't build up in the queue and it was also necessary to allow us to
experiment with several methods of trying to catch the server shutdown.
However, I think I said something to the effect of ``hopefully this will
allow us to catch a server shutdown...''.  That is, I didn't currently have
a solution.

> Also (it's probably more work but...) the X server is the one handling
> the clipboard, isn't it? So if xwinclip is integrated into the server,
> it should not need to be a X client anymore so no more problem with
> connections. Maybe Chris would be interested into looking into that
> (that would occupy his mind for quite a while a guess :)).
>

The problem here is that the clipboard interface is actually a
client-interface.  I don't know that the server has anything at all to do
with the clipboard.  The fact that the clipboard interface is part of the
ICCCM (Inter-Client Communications Conventions Manual, or something like
that) seems to suggest that this is the case.  So, in order to call these
client functions you need a client connection, thus the problem with needing
to know when the client disconnects.


With all of that being said, it may turn out that the best way to solve this
problem is just to throw a Cygwin-specific hook into the dix functions that
handle a server shutdown or reset.  This Cygwin-specific hook would just
notify the clipboard client embedded in the server that the server is about
to reset so the client connection should be closed.  That may turn out to be
the only way to handle this.

Harold