6

上下文：Ubuntu 11.10 和 libfuse 2.8.4-1.4ubuntu1 Linux 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

我正在尝试使用 libfuse。我想让 fuse_session_loop 退出（从信号处理程序或不同的线程），但是当我调用 fuse_session_exit 时，在会话收到新请求之前什么都不会发生。

fuse_session_exit 设置一个由 fuse_session_exited 读取的标志。调试到 fuse_session_loop 它似乎阻塞了 fuse_chan_recv，所以它不会再次检查 fuse_session_exited 直到循环的顶部......

int fuse_session_loop(struct fuse_session *se)
{
    int res = 0;
    struct fuse_chan *ch = fuse_session_next_chan(se, NULL);
    size_t bufsize = fuse_chan_bufsize(ch);
    char *buf = (char *) malloc(bufsize);
    if (!buf) {
        fprintf(stderr, "fuse: failed to allocate read buffer\n");
        return -1;
    }

    while (!fuse_session_exited(se)) {
        struct fuse_chan *tmpch = ch;
        res = fuse_chan_recv(&tmpch, buf, bufsize); <--- BLOCKING
        if (res == -EINTR)
            continue;
        if (res <= 0)
            break;
        fuse_session_process(se, buf, res, tmpch);
    }

    free(buf);
    fuse_session_reset(se);
    return res < 0 ? -1 : 0;
}

fuse_chan_recv 调用 fuse_kern_chan_receive 阻塞“/dev/fuse”设备的“read”系统调用，因此即使设置了 fuse_session_exited 标志，也没有任何反应。

static int fuse_kern_chan_receive(struct fuse_chan **chp, char *buf,
                  size_t size)
{
    struct fuse_chan *ch = *chp;
    int err;
    ssize_t res;
    struct fuse_session *se = fuse_chan_session(ch);
    assert(se != NULL);

restart:
    res = read(fuse_chan_fd(ch), buf, size); <--- BLOCKING
    err = errno;

    if (fuse_session_exited(se))
        return 0;
    if (res == -1) {
        /* ENOENT means the operation was interrupted, it's safe
           to restart */
        if (err == ENOENT)
            goto restart;

        if (err == ENODEV) {
            fuse_session_exit(se);
            return 0;
        }
        /* Errors occuring during normal operation: EINTR (read
           interrupted), EAGAIN (nonblocking I/O), ENODEV (filesystem
           umounted) */
        if (err != EINTR && err != EAGAIN)
            perror("fuse: reading device");
        return -err;
    }
    if ((size_t) res < sizeof(struct fuse_in_header)) {
        fprintf(stderr, "short read on fuse device\n");
        return -EIO;
    }
    return res;
}

这个问题似乎影响了 libfuse 提供的 hello_ll.c 示例以及我的程序。这让我觉得也许有一些机制不应该起作用。也许 fuse_session_exit 也应该做一些中断读取调用的事情，由于某种原因在我的系统上不起作用。

有任何想法吗？

4

4 回答 4

2

这可能值得一个错误报告；它也可能因“按预期工作”而关闭。

也就是说，如果您还发送一个信号来中断函数中read()执行的调用fuse_kern_chan_receive()，它似乎准备通过堆栈向上传播错误，这将触发continue更高级别的调用，它会注意到exited标志，并希望终止循环尽可能干净。

尝试添加一个pthread_kill(3)来杀死有问题的特定线程。为,和那个调用fuse_signals.c安装处理程序。SIGHUPSIGINTSIGTERMfuse_session_exit()

于 2012-01-18T00:30:00.943 回答
1

通常，如果在系统调用（例如read(2)）阻塞时执行信号处理程序，则系统调用会立即返回（在信号处理程序完成执行后）并返回EINTR。这显然是fuse_session_loop和fuse_session_exit设计的行为。

但是，如果安装了信号处理程序并设置了SA_RESTART标志（请参阅sigaction(2) ），则在信号处理程序执行后系统调用将不会返回EINTR 。系统调用将恢复阻塞。

由于某种原因，在我的系统（Ubuntu 11.10 x86_64）上， signal(2)的默认行为是安装带有SA_RESTART标志的信号处理程序。

即以下程序的strace ...

#include <stdlib.h>
#include <signal.h>

void f(int signum) {}

int main()
{
    signal(SIGINT,f);
    return EXIT_SUCCESS;
}

……如下……

rt_sigaction(SIGINT, {0x400524, [INT], SA_RESTORER|SA_RESTART, 0x7f4997e1f420}, {SIG_DFL, [], 0}, 8) = 0

出于这个原因，信号（在 fuse 和我自己的程序提供的示例中）没有像他们的作者所期望的那样中断fuse_kern_chan_receive中的阻塞读取。

解决方法是使用sigaction(2)（并将SA_RESTART位设为零）来安装处理程序（而不是signal(2)）。

仍然存在的一个悬而未决的问题是，为什么对signal(2)的调用默认开启SA_RESTART标志？我希望中断（不重新启动）是预期的默认行为。

于 2012-01-18T22:41:06.310 回答
1

我无法通过将保险丝 2.9.2 的SA_RESTART标志归零来解决问题。

相反，当我想退出时，我使用了假读。

  1. 调用前打开文件fuse_session_exit
  2. 称呼fuse_session_exit
  3. 从文件中读取一个字节
于 2018-04-08T14:50:47.457 回答
0

阅读有关信号的手册页：http: //man7.org/linux/man-pages/man2/signal.2.html

signal() 的行为因 UNIX 版本而异，并且在历史上因 Linux 的不同版本而异。避免使用它：使用 sigaction(2) 代替。请参阅下面的可移植性。

signal() 的唯一可移植用途是将信号的处置设置为 SIG_DFL 或 SIG_IGN。使用 signal() 建立信号处理程序时的语义因系统而异（POSIX.1 明确允许这种变化）；不要将其用于此目的。

Linux上的情况如下：

  • 内核的 signal() 系统调用提供了 System V 语义。

  • 默认情况下，在 glibc 2 及更高版本中，signal() 包装函数不会调用内核系统调用。相反，它使用提供 BSD 语义的标志调用 sigaction(2)。只要定义了 _BSD_SOURCE 功能测试宏，就会提供此默认行为。默认情况下，_BSD_SOURCE 被定义；如果定义了_GNU_SOURCE，它也是隐式定义的，当然也可以显式定义。

  • 在 glibc 2 及更高版本上，如果未定义 _BSD_SOURCE 功能测试宏，则 signal() 提供 System V 语义。（如果在其中一种标准模式（-std=xxx 或 -ansi）中调用 gcc(1) 或定义各种其他功能测试宏，例如 _POSIX_SOURCE、_XOPEN_SOURCE 或 _SVID_SOURCE，则不提供 _BSD_SOURCE 的默认隐式定义；参见 feature_test_macros (7).)

所以 GLibc 曾经有信号不会在之后重新启动，但他们对其进行了更改以使其与 BSD 更兼容。

于 2014-11-17T22:34:59.960 回答