Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!argv
From: argv@turnpike.Eng.Sun.COM (Dan Heller)
Newsgroups: comp.windows.x
Subject: Re: XtAddTimeOut() and Timed Interrupts.
Message-ID: <141292@sun.Eng.Sun.COM>
Date: 24 Aug 90 06:40:26 GMT
References: <9008231943.AA01202@crc.skl.dnd.ca>
Sender: news@sun.Eng.Sun.COM
Organization: O'Reilly && Associates
Lines: 36

In article <9008231943.AA01202@crc.skl.dnd.ca> jgraham@CRC.SKL.DND.CA (Jay Graham) writes:
>     We are developing an application on 386/ix and will need time
>     interrupts in the 10s of milleseconds range, however when using
>     XtAddTimeOut() with a 10ms interval we seem to be actually getting
>     around a 20ms interval.  We assume that maybe there are communication
>     delays that cause the discrepancy.  Obviously since the resolution
>     is better than one second, XtAddTimeOut does not use the Unix alarm
>     system call.  We would like to know how XtAddTimeOut (or the X server)
>     is implemented so that it can get millsecond resolution so that we
>     can develop something similar ourselves.

Don't try to develop something similar -- this is the best resolution
you're going to get, all things considered.  XtAddTimeOut() is closely
tied to the select() system call.  this is the ultimate system call that
returns when either
    1) there is data on the X connection to read
    2) select() times out first.
The timeout for select() is based on the interval value in XtAddTimeOut().
Please refer to select() for more details on how this works.

The possible reason for it taking longer than expected is that it
takes some time for the state of the machine to go from the place
where you _set_ XtAddTimeOut() and the place where the select()
call actually gets called.

You aren't going to get any better resolution than this -- you don't
want to use unix signals because they are going likely going to
interrupt a system call (e.g., the read() call that is reading the
next data packet from the  X connection) and you are going to end
up with corrupted data.

--
dan
----------------------------------------------------
O'Reilly && Associates   argv@sun.com / argv@ora.com
Opinions expressed reflect those of the author only.