如何解决linux伪终端打开选择读取
我有以下场景:有人通过打开 /dev/ptmx 创建了一个伪终端。新终端被创建并命名为例如 /dev/pts/2。然后,在我的程序中,我打开 /dev/pts/2 进行阅读。但我也打开其他设备进行读取并使用 select()
函数来等待任何传入的数据。当没有数据到达太长时间时,选择还指定了一些超时来执行其他操作。成功选择后,我使用 read()
函数读取数据,然后将其打印在屏幕上。
如果伪终端被创建者关闭,我会遇到问题。在这种情况下,select
函数立即结束表示成功,而 read
结束则通过返回零表示“无数据”。恕我直言,问题是在这种情况下,无论是选择还是读取都不会返回错误。我应该如何处理这个以检测到终端不再存在?
Status processData()
{
fd_set readFileDescriptorSet; // defined somewhere else
int maxFileDescriptor; // defined somewhere else
struct timeval timeout; // defined somewhere else
int ret = select(maxFileDescriptor + 1,&readFileDescriptorSet,nullptr,&timeout);
if (!ret) // timeout
return Status::success();
if (ret < 0) // error from select()
return Status::error("select error");
ssize_t rd;
char buff[10];
do {
rd = read(interfaces.serialPort.getFileDescriptor(),buff,sizeof(buff) - 1);
if (rd > 0) { // some data has been read
buff[rd] = '\0';
std::cout << buff;
}
} while (rd > 0);
if (rd < 0) // error from read()
return Status::error("read error");
return Status::success();
}
虽然我打开伪终端的方式如下:
Status internalOpen(std::string fileName)
{
close();
fileDescriptor = ::open(fileName.c_str(),O_RDWR | O_NOCTTY | O_NONBLOCK);
if (fileDescriptor == -1)
return Status::error("Terminal::internalOpen::open('" + fileName + "')");
struct termios attributes;
if (tcgetattr(fileDescriptor,&attributes))
return Status::error("Terminal::internalOpen::tcgetattr()");
setAttributes(attributes);
if (tcsetattr(fileDescriptor,TCSANOW,&attributes))
return Status::error("Terminal::internalOpen::tcsetattr()");
return Status::success();
}
void setAttributes(struct termios &attributes)
{
cfmakeraw(&attributes);
cfsetspeed(&attributes,Config::baudRate);
attributes.c_iflag &= ~(IXOFF | IXANY);
attributes.c_oflag &= ~(ONLCR);
attributes.c_lflag &= ~(ECHOE);
attributes.c_cflag &= ~(CSTOPB | CRTSCTS);
attributes.c_cflag |= CREAD | CLOCAL;
attributes.c_cc[VMIN] = 0;
attributes.c_cc[VTIME] = 0;
}
解决方法
在 select()
返回指示有内容要读取后,显示的代码重复循环尝试从非阻塞文件描述符 read()
直到它为 0:
do {
rd = read( ...
} while (rd > 0);
这当然是合理的。除了关闭的连接导致第一个 read()
返回 0,显示的逻辑无法区分。
这里真正需要的只是在 read()
返回 0 之前跟踪是否已读取任何内容。但如果 read()
立即返回 0,则您的鹅已煮熟。
此外,还有一些其他改进将使事情变得更加健壮。
-
select()
返回后,实际检查文件描述符的位是否在readFileDescriptorSet
中保持设置。所示的逻辑只是通过检查所有其他可能性来假设它是。尽管如此,这还是有些脆弱。如果修改了一些切向相关的内容(即,另一个文件描述符被混入其中),很容易忘记这个假设。 - 使用
poll()
而不是select()
,并明确检查POLLHUP|POLLRDHUP
中的revents
。在poll()
接口中更明确地调用文件描述符关闭条件。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。