Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!pasteur!cory.Berkeley.EDU!dheller
From: dheller@cory.Berkeley.EDU (Dan Heller)
Newsgroups: comp.windows.x
Subject: Re: Unix Signals and Xlib
Keywords: Signal, Unix, X11
Message-ID: <5933@pasteur.Berkeley.EDU>
Date: 24 Sep 88 05:49:09 GMT
References: <148@poseidon.UUCP>
Sender: news@pasteur.Berkeley.EDU
Reply-To: dheller@cory.Berkeley.EDU.UUCP (Dan Heller)
Lines: 43

In article <148@poseidon.UUCP> fred%athsys.uucp@sun.com (Fred Cox) writes:
>We have an application that includes a real time simulator that needs
>timer events, and also does things that can take a while during which
>we can't conveniently process X events.

The first thing to remember is that your application doesn't run
synchronously with the server.  A very common mistake to make when
writing programs that deal with SIGALARMs, is that you are likely to
interrupt a communication with the server and will probably send an
incorrect packet across the wire.  The more you timeout, the more
likely this is going to happen.

Of course, this is very application dependent.  I learned my lesson
with my X version of qix -- a simulation of a video game.  This thing
wants to timeout every 40000-usecs to move the objects on the screen,
but it interrupts user interaction (events).  I eventually took out
the timeouts altogether and ended up doing something like:
    loop {
	if (XPending()) {
	    XNextEvent();
	    process_event();
	}
	do_stuff_or_continue_with_stuff();
    }

However, since writing that code, I've found the best way to handle
timeouts (to a surprisingly fine granularity) is to use the toolkit
timeout functions.  XtAddTimeOut() etc...

>Apparently our solutions cause big problems, though.  We get lots
>of errors like: "sequence lost!", and "XError( 1): 
>XID(000000), Serial(1964/2101) Minor(  0) Major(0)".

that's cuz you interrupted sokmething being sent to the server,
went to handle a timeout and called another Xlib call -- the pack
the server got was undoubtly full of garbage.

>Can anyone suggest another scheme that will get around these problems?
If you can't use the toolkit, then you're not going to get good IO at
all (see qix).  Otherwise, if someone else has some helpful info, I'd
like to know about it, too :-)

Dan Heller