Strange exception throw - assign: Operation not permitted

Question

I want to do asynchronous read from cin therefore I have a piece of code

client.h

...
boost::asio::posix::stream_descriptor input;
boost::asio::streambuf input_buffer

client.cpp

Client::Client(int argc, char **argv, boost::asio::io_service &io_service)
    : tcp_socket(io_service)
    , udp_socket(io_service)
    , input(io_service, ::dup(STDIN_FILENO))
{
    ...
    read_std_input();
}

void Client::read_std_input() {
    async_read_until(input, input_buffer, '\n',
                     boost::bind(&Client::handle_std_read, this,
                                 boost::asio::placeholders::error,
                                 boost::asio::placeholders::bytes_transferred));
}

The problem is: when I run my client the normal way [ ./client ] and then input something via command like, it works like charm. However, when I run it via [ ./client < test ] it throws :

terminate called after throwing an instance of 'boost::exception_detail::clone_impl

' what(): assign: Operation not permitted Aborted

Do you have an idea of what the problem might be? Thanks!

Answer 1

Boost.Asio's POSIX stream-oriented descriptors explicitly do not support regular files. Hence, if test is a regular file, then ./client < test will result in posix::stream_descriptor::assign() failing when attempting to assign STDIN_FILENO to the stream_descriptor. The documentation states:

Boost.Asio includes classes added to permit synchronous and asynchronous read and write operations to be performed on POSIX file descriptors, such as pipes, standard input and output, and various devices (but not regular files).

Consider passing the contents of the test file to client through a pipe.

$ cat test | ./client

---

Here is a complete example program and demonstration:

#include <iostream>
#include <boost/asio.hpp>

void handle_read(
  const boost::system::error_code& error,
  std::size_t bytes_transferred
)
{
  std::cout << "read " << bytes_transferred << " bytes with "
            << error.message() << std::endl;
}

int main()
{
  boost::asio::io_service io_service;
  boost::asio::posix::stream_descriptor input(io_service);

  // Assign STDIN_FILENO to the stream_descriptor.  It will support
  // pipes, standard input and output, and various devices, but NOT
  // regular files.
  boost::system::error_code error;
  input.assign(STDIN_FILENO, error);
  if (error)
  {
    std::cerr << error.message() << std::endl;
    return -1;
  }

  boost::asio::streambuf input_buffer;
  async_read_until(input, input_buffer, '\n', &handle_read);
  io_service.run();
}

Demonstration

$ ./client
testing standard inputenter
read 23 bytes with Success
$ echo "this is a test" > test
$ ./client < test
Operation not permitted
$ cat test | ./client
read 15 bytes with Success

Answer 2

Boost asio, on Linux, uses the epoll system by default which does not support files.

But there's a workaround: if you define BOOST_ASIO_DISABLE_EPOLL then asio will revert to the select system and files will work.

Answer 3

Asynchronous file I/O on Linux is still rather primitive. Although the ASIO support for asynchronous file I/O works well in Windows, I haven't had much (...er any) luck using it on Linux.

This is a previous SO question that provides some background on the issue.

Answer 4

Can you try with this minimal reproducer? It works on my Ubuntu 64-bit box:

#include <boost/asio.hpp>
#include <boost/asio/posix/stream_descriptor.hpp>

#include <iostream>

int main()
{
    using namespace boost::asio;

    io_service io;
    posix::stream_descriptor input(io);

    input.assign(STDIN_FILENO);
    streambuf input_buffer;

    std::function<void()> loop = [&] {
        async_read_until(input, input_buffer, '\n', [&](boost::system::error_code ec, size_t) {
            if (ec) 
                std::cerr << ec.message();
            else {
                std::cout << "LOOP: '" << &input_buffer << "'\n";
                loop();
            }
        });
    };

    loop();
    io.run();
}

Update I think I can reproduce the problem on Coliru: can you check the output of ulimit -a?