jsol@bbnccv.ARPA (01/30/85)
The code is:
boolean io_haschar(infile)
FILE *infile;
{
int readfds, nfound;
struct timeval timeout;
timeout.tv_sec = 10;
timeout.tv_usec = 0;
readfds = (1<<fileno(infile));
nfound = select(1, &readfds, 0, 0, &timeout);
if (nfound == 0)
return(FALSE);
if (readfds&(1<<fileno(infile)))
return (TRUE);
else
return(FALSE);
}
timeval is declared in sys/time.h.
The problem is: When I call this peice of code, it times out,
claiming infile has no characters ready to read. Examination of the
data stream (with a line monitor) indicates that a character is being
sent to the program, but somehow the program doesn't notice.
We are running Ultrix-32, and note the following disclaimer in the
documentation for select(2).
STATUS
SELECT(2) currently is not supported by Digital Equipment
Corporation.
Any hints as to what I'm doing wrong (if I am doing something wrong?)
Thanks,
--JSolguy@rlgvax.UUCP (Guy Harris) (01/30/85)
> boolean io_haschar(infile) > FILE *infile; > ... > readfds = (1<<fileno(infile)); > > nfound = select(1, &readfds, 0, 0, &timeout); > > if (nfound == 0) > return(FALSE); "fileno(infile)" must be zero for this to work. I don't have the original 4.2BSD or ULTRIX-32 documentation, so it may be ambiguous on this point, but my 4.2BSD manual says: "Nfds" descriptors are checked, i.e. the bits from 0 through "nfds"-1 in the masks are examined. I.e., "nfds" (the first argument to "select") is not the number of one bits in all the masks (which is 1 in this case), but the highest bit to be examined plus one (i.e., 32 is probably a nice number, as it's greater than the 20 that is usually the size of a descriptor table, and is also the number of bits in an "int" on machines that are 1) reasonable and 2) can support 4.2BSD). > We are running Ultrix-32, and note the following disclaimer in the > documentation for select(2). > > STATUS > SELECT(2) currently is not supported by Digital Equipment > Corporation. *THAT'S* amusing. I'd be curious to see what they do, and don't, support; a HECK of a lot of networking code uses "select". Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
Bob Walsh <walsh@bbn-labs-b.ARPA> (01/30/85)
The first argument to select is incorrect. You should use: fileno(fp)+1 bob walsh
Doug Gwyn (VLD/VMB) <gwyn@Brl-Vld.ARPA> (01/30/85)
Indeed, select() is probably the most generally useful new feature in 4.2BSD. Even AT&T plans to add select() at some future date (according to their network developers).
keesan@bbncca.ARPA (Morris M. Keesan) (01/30/85)
------------------------------------------------- > > We are running Ultrix-32, and note the following disclaimer in the > > documentation for select(2). > > > > STATUS > > SELECT(2) currently is not supported by Digital Equipment > > Corporation. > *THAT'S* amusing. I'd be curious to see what they do, and don't, support; > a HECK of a lot of networking code uses "select". > Guy Harris > {seismo,ihnp4,allegra}!rlgvax!guy ------------------ The list of things they don't "support" is indeed amusing. Of course, the "currently not supported" disclaimer doesn't imply at all that the item in question won't work, merely that they haven't yet had time to go through and certify the particular piece of software. The most amusing non-support I've found so far is STATUS FORK(2) currently is not supported by Digital Equipment Cor- poration. The mind boggles. -- Morris M. Keesan {decvax,linus,ihnp4,wivax,wjh12,ima}!bbncca!keesan keesan @ BBN-UNIX.ARPA
thomas@utah-gr.UUCP (Spencer W. Thomas) (01/30/85)
In article <7834@brl-tgr.ARPA> jsol@bbnccv.ARPA writes: >timeval is declared in sys/time.h. > >The problem is: When I call this peice of code, it times out, >claiming infile has no characters ready to read. Examination of the >data stream (with a line monitor) indicates that a character is being >sent to the program, but somehow the program doesn't notice. If you do not have your terminal line in either CBREAK or RAW mode, there are NO characters AVAILABLE TO READ until a newline is received. -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) <<< Silly quote of the week >>>
Ron Natalie <ron@BRL-TGR.ARPA> (01/31/85)
You must put support for select in the individual drivers. If a driver doesn't have the select entry in devsw filled in, select won't work. We noticed this as well on some other computers which don't do select on their consoles. Consequently you can't use telnet on that device. I can't believe DEC would take select out of things that already have it, but they may not have put it into any new drivers that they have written. -Ron
dav@ucb-vax.ARPA (02/05/85)
Gee, since no one else has gotten this right yet I guess I'll chip in my two cents worth. >From jsol@BBNCCV.ARPA Tue Jan 29 18:12:59 1985 remote from ucivax >boolean io_haschar(infile) >FILE *infile; >{ > int readfds, nfound; > struct timeval timeout; > > timeout.tv_sec = 10; > timeout.tv_usec = 0; > > readfds = (1<<fileno(infile)); > > nfound = select(1, &readfds, 0, 0, &timeout); <----- Vital line! > > if (nfound == 0) > return(FALSE); > if (readfds&(1<<fileno(infile))) > return (TRUE); > else > return(FALSE); >} >The problem is: When I call this peice of code, it times out, >claiming infile has no characters ready to read. Examination of the >data stream (with a line monitor) indicates that a character is being >sent to the program, but somehow the program doesn't notice. Your problem has nothing to do with DEC support (but I'm not surprised that everyone jumped on that as a possible reason instead of looking for code errors). Your problem has to do with the first argument to select on the line I flagged above. This argument is documented as "nfds", the number of file descriptors to look at. Your choice of 1 means that select only looks at lines "0 through N-1", or just 0. Of course, your readfds mask tells select to ignore all but "fileno(infile)", which probably isn't 0. I suggest changing that first arg to 32 (or better yet, fileno(infile)+1). This should solve your problem. David L. Markowitz Rockwell International ...!ucbvax!{ucivax,trwrb}!csuf!dav