home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!spool.mu.edu!sdd.hp.com!sgiblab!nec-gw!nec-tyo!wnoc-tyo-news!scslwide!wsgw!wsservra!onoe
- From: westhawk!thp@scslwide.sony.co.jp (Timothy H Panton)
- Newsgroups: fj.mail-lists.x-window
- Subject: Re: Xt and CPU usage
- Message-ID: <1992Dec29.132906.23846@sm.sony.co.jp>
- Date: 29 Dec 92 13:29:06 GMT
- Sender: onoe@sm.sony.co.jp (Atsushi Onoe)
- Distribution: fj
- Organization: Workstation Div., Supermicro Systems Group, Sony Corporation
- Lines: 32
- Approved: michael@sm.sony.co.jp
-
- Date: Tue, 29 Dec 92 11:06:49 GMT
- Message-Id: <9212291106.AA13233@westhawk.uucp>
- X-Sun-Charset: US-ASCII
- Content-Length: 1337
-
-
- > Each application is driven by both the GUI and serialized data using
- > XtInputCallbackProc's.
-
- > 2 applications will put CPU usage of a Sparc 2 at 97%, even when
- > completely idle with no serialized data input and no X events (GUI input).
-
- At a guess I'd say you have your XtInputCallbackProc reading from a file.
- (as opposed to a socket or pipe or stream).
- The action of XtAppAddInput is deliberately loosely defined, on most UN*X
- systems it calls select() or poll(). If select() replies "ready" for a given
- file descriptor then your XtInputCallbackProc will get called.
-
- On most Un*X's select() for readability on an open file gives "ready" even
- if you are at the end of file. A (hack) way around this is to
- popen("tail -f filename");
- and use the returned pipe instead of your file descriptor.
-
- Other things to check for are timers and work procs.
-
- Tim.
- +----------------------------------------------------------------------------+
- |Tim Panton, Westhawk Ltd. "Couldn't you make this a little easier for me?" |
- |Phone: +44 244 314800 "Nope. This is as easy as it gets." |
- |Email: thp%westhawk.uucp@uknet.ac.uk |
- |Paper: Westhawk Ltd. Archway House, Station Road, Chester. CH1 3DW. UK |
- +----------------------------------------------------------------------------+
-