Switch a fd between blocking and non-blocking mode?
Hi Everyone, I have one more question related to my problem of my program losing data. I want to ensure I'm not using an anti-pattern that's causing the problem. I have a worker thread that blocks on read(2). When the read() occurs, the fd is switch from blocking to non-blocking. Additional reads are performed until EAGAIN or EWOULDBLOCK. Then the fd is switched back to blocking mode. Does switching a socket between blocking and non-blocking mode cause the kernel to reset or delete queued data (that has not been read by the application yet)? Thanks in advance. Jeff ---------- Here are the functions that switch between blocking and non-blocking mode. There's not much to them. void make_blocking_fd(int fd) { const int old = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, old & ~(int)O_NONBLOCK); } void make_nonblocking_fd(int fd) { const int old = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, old | (int)O_NONBLOCK); }
Hi, Jeffrey. I have looked into the sources of the kernel 4.19.13. After the series of checks the fcntl(F_SETFL) just stores flags into the file descriptor, and that's all: fs/fcntl.c: | int setfl(int fd, struct file * filp, unsigned long arg) | { | int error = 0; | ... | if (filp->f_op->check_flags) | error = filp->f_op->check_flags(arg); | | if (!error && filp->f_op->setfl) | error = filp->f_op->setfl(filp, arg); | | if (error) | return error; | ... | /* #define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | O_DIRECT | O_NOATIME) */ | filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK); | ... | return error; | } You can see two filesystem-specific hooks above, ->check_flags() and ->setfl(). But, to my surprise, ->setfl() is not used by any filesystem in the kernel tree. ->check_flags() is used by nfs only, and just checks the flags, as it's name suggests. Regards, Konstantin Andreev Jeffrey Walton, 12 Nov 2019 02:21 MSK:
I have one more question related to my problem of my program losing data. I want to ensure I'm not using an anti-pattern that's causing the problem.
I have a worker thread that blocks on read(2). When the read() occurs, the fd is switch from blocking to non-blocking. Additional reads are performed until EAGAIN or EWOULDBLOCK. Then the fd is switched back to blocking mode.
Does switching a socket between blocking and non-blocking mode cause the kernel to reset or delete queued data (that has not been read by the application yet)? ----------
Here are the functions that switch between blocking and non-blocking mode. There's not much to them.
void make_blocking_fd(int fd) { const int old = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, old & ~(int)O_NONBLOCK); }
void make_nonblocking_fd(int fd) { const int old = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, old | (int)O_NONBLOCK); }
On Wed, Nov 13, 2019 at 4:59 AM Konstantin Andreev <andreev@swemel.ru> wrote:
I have looked into the sources of the kernel 4.19.13.
After the series of checks the fcntl(F_SETFL) just stores flags into the file descriptor, and that's all:
Ack, thanks. I did not think the kernel discarded the data when switching the mode. (a tcflush or tcdrain may do it, but I did not call them). I'm almost certain there's a bug in the firmware on the modem I am using. Jeff
participants (2)
-
Jeffrey Walton -
Konstantin Andreev