[comp.windows.x] What is the politically correct way...

kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (05/26/90)

to detect that the server has closed the connection to a client?

I have a (psuedo?) client that only sends XEvents to other clients.
When the user ends a session and logs out (under xdm) the server resets
and closes all client connections.  Since my client is not reading
the event queue, it does not detect the closure until the next time it
tries to send.  I'd like to detect the closure, and do a gracefull exit,
rather than suffer the consequences of Xlib exit()ing for me.

I'm running under SunOS 4.0.3/4.1, so I have select() available as an option.
In fact, I tried select()ing on error conditions on the display->fd, but this
always seems to indicate an error.  I'm going to keep playing with it, but
I'd appreciate any ideas/thoughts others might have.

Thanks.

kaleb@thyme.jpl.nasa.gov            Jet Propeller Labs
Kaleb Keithley

kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (05/26/90)

I know it's bad form to follow up your own article, but...

In article <3833@jato.Jpl.Nasa.Gov> I wrote
>to detect that the server has closed the connection to a client?
>
>I have a (psuedo?) client that only sends XEvents to other clients.
>When the user ends a session and logs out (under xdm) the server resets
>and closes all client connections.  Since my client is not reading
>the event queue, it does not detect the closure until the next time it
>tries to send.  I'd like to detect the closure, and do a gracefull exit,
>rather than suffer the consequences of Xlib exit()ing for me.

What I have found to work is to periodically do a select(), testing the
ability to write on display->fd.  When select returns an indication that
write is not possible, then I assume the server has closed the connection,
and exit gracefully.

Two questions:
1.  Is this approach reasonable/acceptable.

2.  What risk, if any, is there in never reading from display->fd, i.e.
    never doing a XNextEvent().  In the same vein, does the server ever
    send anything to a client that doesn't create any windows, never
    registers for events, in short, I just XOpenDisplay (), and then
    loop forever doing XSendEvent ()?

kaleb@thyme.jpl.nasa.gov            Jet Propeller Labs
Kaleb Keithley

janssen@parc.xerox.com (Bill Janssen) (05/28/90)

1.  Have your client read the event queue.

2.  Just reading the event queue won't do it.  Use select(2) on input,
not error, and use "ioctl(DisplayNumber(dpy), FIONREAD, &count)" to get
the number of bytes waiting to be read.  When this is 0, but select indicates
that input is available on the connection, you may assume EOF.

Bill
--
 Bill Janssen        janssen.pa@xerox.com      (415) 494-4763
 Xerox Palo Alto Research Center
 3333 Coyote Hill Road, Palo Alto, California   94304

davecb@yunexus.UUCP (David Collier-Brown) (05/28/90)

janssen@parc.xerox.com (Bill Janssen) writes:
>2.  Just reading the event queue won't do it.  Use select(2) on input,
>not error, and use "ioctl(DisplayNumber(dpy), FIONREAD, &count)" to get
>the number of bytes waiting to be read.  When this is 0, but select indicates
>that input is available on the connection, you may assume EOF.

	Hmmn.
	I wonder if this is in part the answer to one of my unanswered
questions of yore...

	I was looking at a means of detecting the disappearance of a
(perfmeter) client, so that I could put up an icon of a little tombstone,
for the immediate attention of the (group of) local system administrators.
Does a second client reading the event queue strike you as a sane approach?

--dave
-- 
David Collier-Brown,  | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | "And the next 8 man-months came up like
CANADA. 416-223-8968  |   thunder across the bay" --david kipling

janssen@parc.xerox.com (Bill Janssen) (05/29/90)

In article <11248@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes:

	   I was looking at a means of detecting the disappearance of a
   (perfmeter) client ...

What is perfmeter (do you mean xmeter?), and what is a client?
--
 Bill Janssen        janssen.pa@xerox.com      (415) 494-4763
 Xerox Palo Alto Research Center
 3333 Coyote Hill Road, Palo Alto, California   94304