Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!rochester!kodak!ispd-newsserver!ism.isc.com!emisle!dvb
From: dvb@emisle.uucp (David Van Beveren)
Newsgroups: comp.windows.x
Subject: Re: Receiving XEvents asynchronously
Message-ID: <1991Jan19.021807.375@emisle.uucp>
Date: 19 Jan 91 02:18:07 GMT
References: <129@crystel.UUCP> <tbecker.664209752@sirius>
Reply-To: dvb@emisle.UUCP (David Van Beveren)
Organization: Emerald Isle Systems, Ltd. Agoura Hills, CA
Lines: 103

In article <tbecker.664209752@sirius> tbecker@sirius.informatik.uni-kl.de (Thomas Becker) writes:
.
.
>I have had the same problem some time ago (using Xlib only).
>In fact X events are nothing else but messages coming in through a socket.
.
.
.
Is this true? That seems like a implementation-dependant thing. In fact,
I know that ISC X rev 1.2 can run without the ISC TCP/IP package. They
have a (dummy?) libinet.a that you link, that comes with the X package.
When you get TCP/IP (if), then you get a "real" libinet.a. 

I have always assumed that you cannot depend on the Xprotocol messages being
delivered over a socket. What about machines that support AT&T TLI only? I
am very interested in this. I have an X application that uses a XtWorkProcess
in the background of the event loop to do a select on an open socket.

The following code is from an application I inherited at one time, and this
(an event loop trying to monitor other sockets besides the 'x socket' does
not work (does not compile if I remember correcty) in the Interactive
configuration that does not include TCP/IP. But, when you add that package,
it works fine.

If someone at Interactive could clear this up I would appreciate it. In
any case, if your application needs to be portable, I would not assume that
X is implemented on top of some BSD socket transport mechanism.

when you add the TCP/IP package, it runs fine.

#include "common.h"
#include <sys/socket.h>


mainloop (dpy, tcpsock)
Display	*dpy;
int	tcpsock;
{
	fd_set		fdmask;
	XEvent		event;
	struct timeval	timeout;
	int		displayFD;
	int		ret;

	/* get file descriptor of TCP stream connection to server */
	displayFD = XConnectionNumber (dpy);

    while (1) {
allock();
	/*
	 * Look for events.  Try to arrange that X events have priority over
	 * network traffic.  See if there's an X event pending.  If so, check
	 * for a net event, too; if not, select on both the network and the X
	 * connection.  If that doesn't time out, but there's no X event
	 * pending, try again, just selecting on the X connection.  If that
	 * times out, let the network event get processed.
	 *
	 * Can't just select on the two fds, because there may be X events
	 * pending in the queue that have already been read.
	 *
	 * This may look baroque, but we've seen some instances where X server
	 * latency seems to let the network events take priority over server
	 * events, leading to sluggish keyboard response and lots of local
	 * death.
	 */

	FD_ZERO (&fdmask);
	tcp_setfds (&fdmask);		/* enable all client fds */

	if (! XPending (dpy)) {		/* nothing on the X connection */
		FD_SET (displayFD, &fdmask);
		while ((ret = select (32, &fdmask, NULL, NULL, (struct timeval *)0)) == -1)
			if (errno != EINTR)
				perror("select error on events(1)");
		if (ret == 0) {
			continue;
		}
	}				/* *** */
	else {
		timeout.tv_sec = 0;
		timeout.tv_usec = 0;
		while ((ret = select (32, &fdmask, NULL, NULL, &timeout)) == -1)
			if (errno != EINTR)
				perror("select error on events(2)");
	}

	/* handle X events */
	if (XPending (dpy)) {
		XNextEvent (dpy, &event);
		HandleEvent (dpy, &event);
	}

	/* handle TCP listener and clients */
	tcp_service_fds (&fdmask);
    }
    /*NOTREACHED*/
}

dvb

David Van Beveren                           INTERNET: emisle!dvb@ism.isc.com
EIS ltd. Professional Software Services     UUCP:   ..uunet!emisle!dvb
voice: (818) 587-1247