Re: [asio-users] New development release - asio version 1.5.3

[Christopher K. <ch...@ko...>]

On Tue, 22 Mar 2011 21:28 +0100, "Boris Schaeling" <bo...@hi...>
wrote:
> It seems to work on POSIX and Windows? It also seems to be possible to
> bind signal_sets to different io_services (they don't need to use one
> central io_service)? It's even possible for multiple signal_sets to
> wait for the same signal (all handlers will be called when the signal
> is triggered)?

Yes, yes and yes (except that only one handler from each signal set is
called).

> I ask as I had tried myself to create a Boost.Asio-like signal handler
> based on a proposal from Dmitry Goncharov (see
> https://svn.boost.org/trac/boost/ticket/2879). As Dmitry had
> criticized my implementation (see
> http://lists.boost.org/Archives/boost/2010/03/164228.php) I would be
> interested to know whether his critique also applies to signal_set's
> implementation. Having looked briefly at the implementation I don't
> see a thread but for example a mutex and a list.

Concerning the non-Windows implementation:

- Preserving errno: I've fixed this now, thanks.

- The signal handler writes to a pipe that's in non-blocking mode.

- All asio-internal file descriptors are now marked FD_CLOEXEC.

- I'm not interested in supporting siginfo, for various reasons.

- It uses only one pipe (i.e. two file descriptors) no matter how many
signal_sets or associated io_services are in use.

- There's no thread. It works even when thread support is disabled.

- There's one global mutex used for protecting access to the signal
registration data structure. The mutex is not touched in the signal
handler itself.

- It uses no STL data structures. Everything's managed using a tree plus
the queues of pending operations.

> I had criticized that Dmitry's proposal doesn't really look like
> anything else in Boost.Asio. But if it's not advertised as a
> Boost.Asio extension, it could make perfectly sense in another
> library. In fact we had discussed adding support for signal handling
> to a future version of (Boost.)Process (and I had even referred to
> Dmitry's code :).
>
> Now I'm interested to hear your opinion. :)

The following snippet might be food for thought:

//------------
class process
{
public:
  process(asio::io_service& io_service,
          const char* path, const char* arg)
    : pid_(-1),
      signal_(io_service, SIGCHLD)
  {
    pid_ = fork();
    if (pid_ == 0)
    {
      execl(path, path, arg, NULL);
    }
  }

  template <typename Handler>
  void async_wait(Handler handler)
  {
    signal_handler<Handler> sh = { pid_, signal_, handler };
    signal_.async_wait(sh);
  }

private:
  template <typename Handler>
  struct signal_handler
  {
    pid_t pid_;
    asio::signal_set& signal_;
    Handler handler_;

    void operator()(asio::error_code ec, int)
    {
      int status;

      for (;;)
      {
        status = 0;
        int result = ::waitpid(pid_, &status, WNOHANG);

        ec = asio::error_code(
            result < 0 ? errno : 0,
            asio::error::get_system_category());

        if (ec == asio::error::interrupted)
          continue;

        if (ec)
          break;

        if (result == pid_)
          if (WIFEXITED(status) || WIFSIGNALED(status))
            break;

        signal_.async_wait(*this);
        return;
      }

      handler_(ec, WEXITSTATUS(status));
    }
  };

  pid_t pid_;
  asio::signal_set signal_;
};
//------------

Cheers,
Chris