Original message on -questions, but this list seems more appropriate. More below. On Sun, 29 Aug 2004 11:35:39 +0200, Tijl Coosemans wrote:> Hi list, > > I think I've found a possible bug in 4-stable, though I'm not that > kind of an expert so I'll leave that decision up to you. > > Attached is a little test program that opens /dev/cuaa0 and tries to > read a couple bytes. > > When compiled using "gcc vtime.c -o vtime" there's no problem. For > example, when you run vtime without anything attached to cuaa0, > it'll wait about 2 seconds and timeout, since VMIN=0 and VTIME=20. > > When compiled using "gcc -pthread vtime.c -o vtime" however, the > read function returns immediately, which as far as I can understand, > is not what it's supposed to do. > > Does anyone know if this intended or not, or how I can get the right > behaviour in a threaded program?I've done some more testing. It appears that when linked with lc_r, VTIME is completely ignored. As explained in termios(4), when VMIN>0, the read call will wait indefinitely for the first byte and then use VTIME as an interbyte timer. When using lc_r however, it'll return immediately after the first couple bytes read, even if that's less than VMIN. The case where VTIME==0 works as it should both with lc and lc_r. I dont have access to a box with -current, so I can't say if the same applies to it. I hope somebody understands this better or could at least give me a few pointers as to where to look in the source code. Thanks, tijl -------------- next part -------------- #include <fcntl.h> #include <stdio.h> #include <sys/types.h> #include <termios.h> #include <unistd.h> extern int errno; int main(void) { int fd, len; struct termios termset; uint8_t data[256]; fd = open("/dev/cuaa0", O_RDWR | O_FSYNC); printf("%d %d\n", fd, errno); if (fd != -1) { tcgetattr(fd, &termset); cfmakeraw(&termset); cfsetspeed(&termset, B9600); termset.c_cc[VMIN] = 1; termset.c_cc[VTIME] = 0; tcsetattr(fd, TCSANOW, &termset); len = read(fd, (void *) data, 3); printf("%d\n", len); close(fd); } return 0; }
On 30 Aug, Tijl Coosemans wrote:> I've done some more testing. It appears that when linked with lc_r, > VTIME is completely ignored. > > As explained in termios(4), when VMIN>0, the read call will wait > indefinitely for the first byte and then use VTIME as an interbyte > timer. When using lc_r however, it'll return immediately after the > first couple bytes read, even if that's less than VMIN. > > The case where VTIME==0 works as it should both with lc and lc_r.This is not suprising. The way libc_r handles I/O is that it puts all the descriptors in non-blocking mode and uses poll() to figure out which threads to run. To work properly, libc_r would have to emulate VMIN internally.> I dont have access to a box with -current, so I can't say if the same > applies to it.I would expect the same behaviour with libc_r on -CURRENT, but the other thread libraries should work properly.> I hope somebody understands this better or could at least give me a > few pointers as to where to look in the source code. > > Thanks, tijl
this should have been sent to -threads..
--------------------------------------------
>Hi list,
>>
>> I think I've found a possible bug in 4-stable, though I'm not
that
>> kind of an expert so I'll leave that decision up to you.
>>
>> Attached is a little test program that opens /dev/cuaa0 and tries to
>> read a couple bytes.
>>
>> When compiled using "gcc vtime.c -o vtime" there's no
problem. For
>> example, when you run vtime without anything attached to cuaa0,
>> it'll wait about 2 seconds and timeout, since VMIN=0 and VTIME=20.
>>
>> When compiled using "gcc -pthread vtime.c -o vtime" however,
the
>> read function returns immediately, which as far as I can understand,
>> is not what it's supposed to do.
>>
>> Does anyone know if this intended or not, or how I can get the right
>> behaviour in a threaded program?
I've done some more testing. It appears that when linked with lc_r,
VTIME is completely ignored.
As explained in termios(4), when VMIN>0, the read call will wait
indefinitely for the first byte and then use VTIME as an interbyte
timer. When using lc_r however, it'll return immediately after the
first couple bytes read, even if that's less than VMIN.
The case where VTIME==0 works as it should both with lc and lc_r.
I dont have access to a box with -current, so I can't say if the same
applies to it.
I hope somebody understands this better or could at least give me a
few pointers as to where to look in the source code.
Thanks, tijl
-------------- next part --------------
#include <fcntl.h>
#include <stdio.h>
#include <sys/types.h>
#include <termios.h>
#include <unistd.h>
extern int errno;
int main(void) {
int fd, len;
struct termios termset;
uint8_t data[256];
fd = open("/dev/cuaa0", O_RDWR | O_FSYNC);
printf("%d %d\n", fd, errno);
if (fd != -1) {
tcgetattr(fd, &termset);
cfmakeraw(&termset);
cfsetspeed(&termset, B9600);
termset.c_cc[VMIN] = 1;
termset.c_cc[VTIME] = 0;
tcsetattr(fd, TCSANOW, &termset);
len = read(fd, (void *) data, 3);
printf("%d\n", len);
close(fd);
}
return 0;
}
On Tue, 31 Aug 2004, Julian Elischer wrote:> > this should have been sent to -threads.. > -------------------------------------------- > >Hi list, > >> > >> I think I've found a possible bug in 4-stable, though I'm not that > >> kind of an expert so I'll leave that decision up to you. > >> > >> Attached is a little test program that opens /dev/cuaa0 and tries to > >> read a couple bytes. > >> > >> When compiled using "gcc vtime.c -o vtime" there's no problem. For > >> example, when you run vtime without anything attached to cuaa0, > >> it'll wait about 2 seconds and timeout, since VMIN=0 and VTIME=20. > >> > >> When compiled using "gcc -pthread vtime.c -o vtime" however, the > >> read function returns immediately, which as far as I can understand, > >> is not what it's supposed to do. > >> > >> Does anyone know if this intended or not, or how I can get the right > >> behaviour in a threaded program? > > > I've done some more testing. It appears that when linked with lc_r, > VTIME is completely ignored.Yes, and it will always be completely ignored. If you want to use libc_r on 4.x, you'll have to work around it (use select() or poll() perhaps). It is not a problem in 5.x which will be the next -stable. -- Dan Eischen