Hi Aitor.

    Indeed, using processes is easier than threads.

Le 17/07/2025 à 00:43, aitor a écrit :
> For a long time the "struct pollfd pfd" defined in the line 56 of
> linux.c:
> https://github.com/jcnelson/vdev/blob/master/vdevd/os/linux.h consists
> of a poll dealing with several file descriptors. I'll add another one
> to handle the pipe you mentioned above. For example: /*
> ------------------ CODE ---------------------------- */
>
> // Enumerate list of FDs to poll
> enum {
>         FD_POLL_SIGNAL = 0,
>         FD_POLL_PIPE,
>         FD_POLL_NETLINK,
>         FD_POLL_MAX
> };
>
> // The poller:
> struct pollfd pfd[FD_POLL_MAX];
>
> //The pid and the pipe used in the fork
> pid_t pid;
> int pipe[2];
>
    OK, as you notice, let it get another name, since pipe(2) is the
function which creates it.
>
>
> // Fork
> pid = fork();
>
> // Parent process
> if (pid > 0) {
>
>         close(pipe[0]);
>
>         /* Setup the polling part concerning to the pipe, and the rest
> as well */
>         pfd[FD_POLL_PIPE].fd = pipe[1];
>         pfd[FD_POLL_PIPE].events = POLLIN;
>         ( .... )
>

    I have a doubt about which end of the pipe you poll: it seems you
poll the write end instead of the read end.

    Then, when the process which scans sysfs is done, it can just exit
(return), which closes the pipe. When the pipe is empty and closed, the
poll() can get an error event from the pipe and it tells the polling
process it is time to reap the other one.

    It seems to me async.h and the libasync are features meant to
abstract the system's methods over various operating systems, including
Windows. Looks to me like a can of worm and a good way to generate
dead-locks and at least inefficiency.

    BTW, the method I suggested doesn't come out of my hat. It sort of
remember having read this idea of "replaying" the device discovery on
the Busybox mailing list, about mdev.

    Cheers.

--     Didier