Skip to content

I O

Jump to bottom
Matt Windsor edited this page Jul 3, 2014 · 1 revision

I/O

Currently, playslave++ contains two different IO systems (termed IO reactors).

Standard input/output (StdIoReactor)

  • Input via standard input, output via standard output
  • Uses the Playslave API
  • Uses select() on POSIX-compliant systems (and dark magic on other systems)

Advantages

  • More well-tested than AsioIoReactor
  • Simpler than AsioIoReactor
  • Does not require an open TCP port
  • Easily debugged (just run playslave)

Disadvantages

  • Does not easily support multiple clients
  • Does not easily support client/server independence (usually playslave must be launched by the client, and will die once the client exits)
  • Not easily portable outside POSIX systems (without dark magic)

TCP/IP (AsioIoReactor)

  • TCP/IP client/server interface
  • Uses the Playslave API
  • Uses the Boost ASIO library

Advantages

  • More portable than StdIoReactor
  • Allows multiple clients
  • Client can easily detach from playslave without killing it

Disadvantages

  • Requires a TCP port
  • Less easy to debug (must use nc, telnet etc)
  • Much more complex (and, likely, buggy)

Why two reactors?

The StdIoReactor was the original IO system, and was written as a stdin/stdout interface for simplicity and correlation with the standard UNIX paradigm of text streams and command chains. However, full duplex process composing is more difficult than originally expected, and this has limited StdIoReactor's usefulness.

We could try using a system such as inetd to lift the StdIoReactor into a TCP server framework, but this poses a few issues:

  • Not portable to all operating systems (whereas TCP/sockets are ubiquitous, and Boost::ASIO relatively portable);
  • Limits flexibility of what can be done;
  • Using a proper asynchronous I/O framework (hopefully) makes the reactor more robust in the long-term; StdIoReactor is somewhat cumbersome in its simplistic design.

We decided to keep StdIoReactor in Playslave++ because it already exists, is more well-tested, is already used by at least one frontend, and could still be useful in some niche cases.

Clone this wiki locally