schoch@ames.arc.nasa.gov (Steve Schoch) (05/24/88)
The X Toolkit Intrinsics document, on page 60, states that the InputCallbackProc will be called with three arguments: caddr_t client_data; int source; XtInputId id; This seems resonable, and I trusted the manual. However, if you look at the source, you will see the actual arguments are: caddr_t client_data; int *source; XtInputId *id; I can't see any reason for passing pointers to these things, so I think the manual has the correct behavior and the library is incorrect. Also, on the same page, XtRemoveInput() is documented as taking one argument: XtInputId *id. It doesn't take a pointer. Have these bugs been fixed? If so, where do I get an update? Steve
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (05/24/88)
Date: 24 May 88 00:14:23 GMT
From: schoch@AMES.ARC.NASA.GOV (Steve Schoch)
int *source;
XtInputId *id;
I can't see any reason for passing pointers to these things, so I
think the manual has the correct behavior and the library is
incorrect.
The manual is incorrect. Callbacks take pointers to things to
facilitate bindings to languages other than C (viz. Ada). As a
different kludge to the same problem, this is also why widgets have a
pointer to self as their first component.
Also, on the same page, XtRemoveInput() is documented as taking
one argument: XtInputId *id. It doesn't take a pointer.
Right.
Have these bugs been fixed? If so, where do I get an update?
Use a red pencil on your manual.mickey@axis.fr (Michael Dance) (07/23/89)
Recently I have been writing a server that receives messages from its clients form sockets (it was from named pipes (FIFO's) but I met a machine that supported select but only on ttys, ptys and sockets - now the server reads on sockets and writes in named pipes - bizarre but named pipes are neater). Everything works OK but while I wrote it I noticed that XtAddInput (and select) allow Exception events to be treated. Alas I haven't found anything to telle me what constitues an event, for example an EOF on a socket is NOT an event. AM I suffereing from culture shock (I'm used to 'pure' system V a la ATT perhaps a BSD fan would already know). Anyway I treat exceptions as link failures and close down the server side for the client whose socket 'exceptioned', is this right? I haven't a clue as I have never received an exception. PS My sockets are TCP Stream sockets PPS To those bickering :) about interface building tools the above mentioned server is part of one such tool that although not as user-friendly as certain micro resource contruction sets does allow easy definition of simple widgets (static text, single line text edit, multi line text edit with vertical scrolling, toggles (pushbutton with two states), scrollng lists and command buttons). It interfaces directly with C programs, callbacks are primitve but supported, updates of user program variables are also fairly simple. AND it also functions on old-fashioned simple terminals (well most of it:) All it needs is a really jazzy X windows graphical interface rather than its curretn ascii definition files and I would be really proud of it, as it is it's just quite good - ps I'm not advertising cos the name of the company I work for is NOT in this message nor in the signature, nor the name of the product. Who wants to be an X guru - I just want to please my customers with recent interfaces.
jhc@ivan.uucp (James H. Coombs) (02/15/91)
I noticed that using XtAddInput() causes my application to consume CPU cycles constantly, even when there is no input. O'Reilly Vol. IV, p. 226 notes: Under the beta release of R4, the function registered with XtAddInput is called very frequently even when no new input is available.... It is difficult to tell whether this is a bug or the intended behavior.... Does anyone have good workarounds for this. (The behavior is unacceptable, whether intended or not.) I can just use my own asynchronous i/o, but I thought that the X model was to let the underlying layers handle the events. I also found that window updating was not very clean, probably because I was adding items to a list before X (Motif) had a chance to update fully. Perhaps I just need to flush the pending events before adding items from my interrupt routine. If I set SIGIO to my signal handler, however, I risk competing with X for those signals. It does not look as though X or Xt uses SIGIO, but that is not guaranteed is it? Any recommendations? --Jim
klee@wsl.dec.com (Ken Lee) (02/15/91)
In article <64966@brunix.UUCP>, jhc@ivan.uucp (James H. Coombs) writes: |> I noticed that using XtAddInput() causes my application to consume CPU |> cycles constantly, even when there is no input. O'Reilly Vol. IV, p. |> 226 notes: |> |> Under the beta release of R4, the function registered with |> XtAddInput is called very frequently even when no new input is |> available.... It is difficult to tell whether this is a bug or |> the intended behavior.... Which implementation are you using? Most Xt UNIX implementations use the select() system call, so this isnt' a problem, unless you're trying to read from regular files, where select() doesn't work. Note that O'Reilly tends to over generalize from one or two examples, so their text may not apply to your system. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
jhc@irwin.uucp (James H. Coombs) (02/15/91)
In article <64966@brunix.UUCP> jhc@ivan.uucp (James H. Coombs) writes: >I noticed that using XtAddInput() causes my application to consume CPU >cycles constantly, even when there is no input.... That's because you invoked XtAddInput not only for the read but also for the write and exception conditions. The socket was always ready to write. The solution is to use XtAddInput for the read condition only, unless you really have something to write. I don't have the answer to your questions on checking the return values. --Jim
adrian@spike.ora.COM (Adrian Nye) (02/18/91)
> > |> I noticed that using XtAddInput() causes my application to consume CPU > |> cycles constantly, even when there is no input. O'Reilly Vol. IV, p. > |> 226 notes: > |> > |> Under the beta release of R4, the function registered with > |> XtAddInput is called very frequently even when no new input is > |> available.... It is difficult to tell whether this is a bug or > |> the intended behavior.... > > Which implementation are you using? Most Xt UNIX implementations use > the select() system call, so this isnt' a problem, unless you're trying > to read from regular files, where select() doesn't work. This is such a common problem that it is described in the Frequently Asked Questions (FAQ) that appear monthly on this list and on motif-talk (Question 39 on the last copy I have). > > Note that O'Reilly tends to over generalize from one or two examples, > so their text may not apply to your system. > -- > Ken Lee In this particularly case, the behavior is as described on many systems, not just one or two (otherwise, why would it be a FAQ?). In the latest editions, the text also qualifies the comment ("On some operating systems...."). We welcome comments from readers who can provide specific comments about how certain features work on various architectures and operating systems. Ken, can you provide a little more information about your counter-examples? ************************************************************* Adrian Nye (314) 531-1231 O'Reilly & Associates, Inc., Publishers of Nutshell Handbooks 90 Sherman Street, Cambridge, MA 02140 UUCP: uunet!ora!adrian ARPA: adrian@ora.com *************************************************************