Portabilty of poll trick

Portabilty of poll trick

[Bastien Roucariès]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

Hi,

I want to assess the safety and portability of the following trick, for getting outside poll. Replacing by using dup2 a read poll object by a writtable one. I think to use this for stopping polling in multithread program
It work really well, and could for instance allow me to tear down eventfd of other event like file that does not support shutdown

CC also   Michael Kerrisk (mtk.manpages@gmail.com) for comments on this trick

#include <errno.h>
#include <poll.h>
#include <pthread.h>
#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>

static void *run_poll (void *arg)
{
    struct pollfd   fds[1];
    int             rc;

    fds[0].fd = ((int *)arg)[0];
    fds[0].events = POLLERR | POLLHUP | POLLNVAL | POLLIN;
 
            //
            // Poll indefinitely
            //

    printf("starting poll\n");
    fflush(stdout);
    rc = poll((struct pollfd *) &fds, 1, -1);

    if ( rc == -1 )
    {
            printf("POLL returned error %d: %s\n", errno, strerror(errno));
    }
    else
    {
            printf("POLL returned %d (revents = 0x%08x): %s %s %s %s %s\n",
                   rc,
                   fds[0].revents,
		   ( ( fds[0].revents & POLLIN  ) ? "pollin" : "noin" ),
		   ( ( fds[0].revents & POLLOUT  ) ? "pollout" : "noout" ),
                   ( ( fds[0].revents & POLLERR  ) ? "pollerr" : "noerr" ),
                   ( ( fds[0].revents & POLLHUP  ) ? "pollhup" : "nohup" ),
                   ( ( fds[0].revents & POLLNVAL ) ? "pollnval" : "nonval" ));
    }

    return  NULL;
}

int main (int argc, char **argv)
{
    pthread_t       thread;
    int             rc;

    int fdst[2];
    pipe(fdst);
    rc = pthread_create(&thread, NULL, run_poll, &fdst);

    sleep(3);
    printf("removing access\n");
    dup2(fdst[0],fdst[1]);
    sleep(3);

    return  0;
}

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Portabilty of poll trick

[Bruno Haible]

Hi Bastien,

> I want to assess the safety and portability of the following trick,

I would want to help you with this, but I can't. You have not stated:
  - What is this code supposed to do?
  - Why is it a "trick"? What advantages does it have compared to the code
    a naïve developer would write?

> for getting outside poll.

I don't understand what you mean here.

Bruno

Re: Portabilty of poll trick

[Bastien ROUCARIES]

Le mar. 27 avr. 2021 à 22:40, Bruno Haible <bruno@clisp.org> a écrit :
>
> Hi Bastien,
>
> > I want to assess the safety and portability of the following trick,
>
> I would want to help you with this, but I can't. You have not stated:
>   - What is this code supposed to do?
I want to shutdown (2) a pipe, in a multithread application, in order
to get out a poll(2) wait state
>   - Why is it a "trick"? What advantages does it have compared to the code
>     a naïve developer would write?
The naive delevopper will:
- close the end of the pipe, but it does not break poll(2), and
moreover in multithread context
it is not safe due to fd reuse
-use timeout but in this case why use poll...

The goal is also to shutdown an eventfd but without kernel support, I
suppose it is not possible...

Bastien
>
>
>
> > for getting outside poll.
>
> I don't understand what you mean here.
>
> Bruno
>

Re: Portabilty of poll trick

[Ben Pfaff]

On Tue, Apr 27, 2021 at 3:47 PM Bastien ROUCARIES
<roucaries.bastien@gmail.com> wrote:
>
> Le mar. 27 avr. 2021 à 22:40, Bruno Haible <bruno@clisp.org> a écrit :
> >
> > Hi Bastien,
> >
> > > I want to assess the safety and portability of the following trick,
> >
> > I would want to help you with this, but I can't. You have not stated:
> >   - What is this code supposed to do?
> I want to shutdown (2) a pipe, in a multithread application, in order
> to get out a poll(2) wait state
> >   - Why is it a "trick"? What advantages does it have compared to the code
> >     a naïve developer would write?
> The naive delevopper will:
> - close the end of the pipe, but it does not break poll(2), and
> moreover in multithread context
> it is not safe due to fd reuse
> -use timeout but in this case why use poll...
>
> The goal is also to shutdown an eventfd but without kernel support, I
> suppose it is not possible...

Can you use socketpair() instead of pipe()?

Re: Portabilty of poll trick

[Bastien ROUCARIES]

Le mar. 27 avr. 2021 à 22:51, Ben Pfaff <blp@cs.stanford.edu> a écrit :
>
> On Tue, Apr 27, 2021 at 3:47 PM Bastien ROUCARIES
> <roucaries.bastien@gmail.com> wrote:
> >
> > Le mar. 27 avr. 2021 à 22:40, Bruno Haible <bruno@clisp.org> a écrit :
> > >
> > > Hi Bastien,
> > >
> > > > I want to assess the safety and portability of the following trick,
> > >
> > > I would want to help you with this, but I can't. You have not stated:
> > >   - What is this code supposed to do?
> > I want to shutdown (2) a pipe, in a multithread application, in order
> > to get out a poll(2) wait state
> > >   - Why is it a "trick"? What advantages does it have compared to the code
> > >     a naïve developer would write?
> > The naive delevopper will:
> > - close the end of the pipe, but it does not break poll(2), and
> > moreover in multithread context
> > it is not safe due to fd reuse
> > -use timeout but in this case why use poll...
> >
> > The goal is also to shutdown an eventfd but without kernel support, I
> > suppose it is not possible...
>
> Can you use socketpair() instead of pipe()?
Yes I can but socket are bidirectionnal and cost more about
memory/speed than pipe.

Bastien

Re: Portabilty of poll trick

[Bruno Haible]

Bastien ROUCARIES wrote:
> - close the end of the pipe, but it does not break poll(2), and
> moreover in multithread context
> it is not safe due to fd reuse

Yes, close() in multithreaded applications needs to be done carefully,
to avoid that unintended operations get done to the next file that
is connected to the same file descriptor. However, I don't see how
a library / abstraction can help here. It's just careful coding of
the application that is needed.

Bruno