synrg/stream2tracks — Issue #16: Handle concurrent processes interactively
Author: synrg
Created: 2011-12-02 18:34:44+00:00
State: open

## Problem

Currently, stream2tracks "cheats" in --multi mode by backgrounding several mplayer instances from a subshell via system(), as starting processes with system() does not itself support concurrency. Furthermore, calling system() is not interactive. This makes any features that relate to handling how backend processes are started and controlled much harder, and stream2tracks current relies heavily on such processes. Moving to a different method of starting processes that supports both concurrency and interaction with the processes will help address a number of existing issues and make it easier to add new features in future.

## Related issues

In issue #14, there is no way to know the minute-by-minute progress of the download of an individual track without some sort of process interaction.

In issue #9, we do not have direct knowledge of the child processes so we can signal them to stop.

In issue #6, particularly in --multi mode, it is difficult to see which output belongs to which track as it is all logged to the same log file.

## Proposal

After some discussion with friends on irc and reading http://en.wikibooks.org/wiki/Ruby_Programming/Running_Multiple_Processes it seems either popen3 or spawn would be ideal, here. The latter is only available in ruby 1.9, but there's no pressing need to have stream2tracks work in 1.8 (and some fallback code could be written if that were ever an issue). See http://www.ruby-doc.org/core-1.9.3/Process.html#method-c-spawn for more details.