checker has asked for the wisdom of the Perl Monks concerning the following question:

I want to have a thread that blocks on a select that's accepting IO::Socket network connections, but I also want to be able to wake it up when a signal comes in. From looking around, it seems like having a pipe read handle in the select set is the way to do this on Unix, and then you write to the pipe to wake up the select. I guess the first question is, is that true?

If it is, then it seems like I'd want to use IO::Pipe, but from reading the docs and source, it really seems like it's designed for two processes, and not for a single process with threads or signals. It doesn't actually look like you can even get both handles out of it without poking around, since a call to either IO::Pipe::reader or writer will close the other handle, since it assumes a fork(). Do I just want to call the raw pipe(R,W) and then wrap them in IO::Handles so I can use IO::Select?

Thanks,
Chris

  • Comment on waking from select, or IO::Pipe in same process?

Replies are listed 'Best First'.
Re: waking from select, or IO::Pipe in same process?
by ikegami (Patriarch) on Jul 13, 2011 at 18:11 UTC

    Yes. select will wake up on pipes. (select's emulation only works on socket in Windows, though.) I wouldn't use select directly, I'd use via IO::Select.

    Pipes are usually used between processes, but they don't have to be. Just make sure you don't fill up the pipe, as that would block the only process that can empty it. I wouldn't bother with IO::Pipe. It doesn't add anything good over pipe.

    If you're using threads, you should look at Thread::Queue.

      Hmm, it looks like IO::Socket::INET's accept already does something with signals. If I install an empty signal handler at the top level, then accept() returns undef cleanly. The perlipc docs show an example of checking for EINTR in this case. I haven't tested IO::Select yet, but I'd assume it behaves the same.

      Chris

        IO::Select is just a thin wrapper around select. accept and select are just thin wrapper around the system calls with the same name. They should return error EINTR when interrupted by a signal (which will only happen if you have a signal handler defined).