jdp@adiron.UUCP (Powell) (02/03/88)
I don't remember this bug being reported before so here goes: ULTRIX 1.2 is semi-4.2BSD compatible but 4.2BSD will not exhibit this bug: Repeat-By: ---------------------------------------------------- Obtain a valid file descriptor such as the value 3. Setup the readfd mask for the select call and issue the following commands twice: readfd = (1 << 3); if (select(getdtablesize(),&readfd,0,0,0) < 0) fprintf(stderr,"Error in select %d\n",errno); else fprintf(stderr,"select ok\n"); The second time and probably all remaining times that select is called, it will fail with the error number corresponding to invalid file descriptor. It does not close the file descriptor. What happens is that some value within the select call is overwritten during the first call and causes subsequent calls to fail. Fix: ---------------------------------------------------- Get ULTRIX sources or get 4.3BSD. :-) Since that is probably to costly the following is provided. Work-around: ---------------------------------------------------- Replace the getdtablesize() with the expression (8 * sizeof readfd) for portability. Explanation: ---------------------------------------------------- It is not getdtablesize() that is broken. Replacing getdtablesize() with the constant NOFILE in /usr/include/sys/param.h will also cause the select call to fail. The reason is that getdtablesize() and NOFILE under standard ULTRIX 1.2 are greater than 32 (namely 64). The readfd parameter is a 32-bit value so it can never tell select() to poll file descriptors 32 - 63 but apparently select() is looking for advice about all 64 descriptors because you told it to. Shame on you :-) This problem took me about 2 weeks of intense effort to find (2 weeks that I didn't have) in code that has worked under 4.2 BSD, 4.3 BSD and under possibly ULTRIX 1.1. The 4.2 BSD worked because getdtablesize() and NOFILE are 20 (less than 32), the 4.3 BSD worked because select was changed to a different format of fd masks. Well, this is a long winded discussion of something nobody does so I'll stop here. John D. Powell PAR Technology adiron!jdp
beirne@richsun.UUCP (Michael G. Beirne) (11/01/89)
Hello, Several programs running under X11R3, like kaleid and xemacs, use the select system call, which does not return after the expected timeout. I have a VAXstation II/GPX running Ultrix 2.2-1. The X server is the one from the distribution X11R3 MIT source. Does anyone know of a work around/fix for this? I just obtained the workstation a few weeks ago and have not been a regular reader of either group, so if this has been gone over before I'm sorry. Michael G. Beirne beirne@richp1.UUCP or beirne@richsun.reuter.com
doug@wiley.uucp (Doug Rudoff) (05/04/90)
On a DECstations 3100 I am trying to do a select() call to see if
there's data to be read from a named pipe. I set the timeout to be 5
seconds. The problem is that it seems that select() does not recognize
that there is data to be read. Here's what I'm doing:
main()
{
struct timeval timeout;
int readfds, n;
cnt_init();
timeout.tv_sec = 5;
timeout.tv_usec = 0;
/* Wait 5 seconds for data on the pipe and then
update status lines */
while (1) {
readfds = 1 << pipe_fd;
n = select(1, &readfds, NULL, NULL, &timeout);
if (n > 0)
read_pipe();
else if (n == -1)
perror("");
do_maintenance();
}
}
select() is always returning a zero (after waiting 5 seconds) even if
there is data in the pipe. I know there is data in the pipe since if I
stop the program in the debugger, I can directly call read_pipe() and
get the data that is there.
I have select() working elsewhere with stdin so I think I'm using it
correctly. Am I doing something wrong here or is there a problem with
select() and pipes in Ultrix 3.1?
Doug Rudoff
Mobile Data International
(206) 487-5937
uunet!mdisea!rudoff, rudoff@MDI.COMfkittred@bbn.com (Fletcher Kittredge) (05/04/90)
In article <9731@wiley.UUCP> rudoff@mdi.com writes: ...Problems with select on a 3100... >main() >{ ... > n = select(1, &readfds, NULL, NULL, &timeout); ... >} > ..it doesn't work for him... Your problem is your first argument to select; you have hardcoded it to '1' when it should be variable. It should always be one greater than the largest file descriptor you are interested in. In this case, it should be (readfds + 1). >I have select() working elsewhere with stdin so I think I'm using it >correctly. Am I doing something wrong here or is there a problem with >select() and pipes in Ultrix 3.1? It works on stdin because with stdin your readfds is 0, so (readfds + 1) is 1.... > >Doug Rudoff >Mobile Data International >(206) 487-5937 >uunet!mdisea!rudoff, rudoff@MDI.COM Fletcher E. Kittredge fkittred@bbn.com Platforms and Tools Group BBN Software Products Company 10 Fawcett St. Cambridge, MA. 02138
hascall@cs.iastate.edu (10/28/90)
after a:
select( ..., exceptfds, ...)
how do I find out what kind of exception has occurred on
the socket(s) indicated in exceptfds? Heck, what *are*
the possible exception conditions? closed? out-of-band data?
urgent data? others?
many thanks,
John Hascall / john@iastate.edu / hascall@atanasoff.cs.iastate.edu