Understanding UIOP/RUN-PROGRAM

[Mark Evenson]

In a potentially memory constrained environment, I need to portably
(across sbcl and ccl at least) process a potentially large (multiple
GiB) stream of bytes output from a Linux command.  For the curious,
"process" here means encrypt with a block cipher and push to the
network; whereas the UNIX command is the output of "btrfs send".

I wanted to confirm with ASDF developers that as far as I can tell from
wrangling with UIOP:RUN-PROGRAM, it isn't going to do what I want
because there is no "asynchronous" mode.  UIOP:RUN-PROGRAM cannot be
"run in the background" like SBCL's SB-EXT:RUN-PROGRAM with :wait nil
that allows the output of the sub-process to be gathered and processed
in blocks.  So, it would always be the case that
UIOP/RUN-PROGRAM::SLURP-INPUT-STREAM has "gone through" all the
(potentially huge) output of the sub-process before UIOP:RUN-PROGRAM can
return.

Note that I'm not complaining about UIOP:RUN-PROGAM: it certainly
bridges a lot of implementation specific details of the use case for
"Execute this command; let me process its output".  I'm just trying to
affirm my understanding of UIOP and (regrettable) need to move off to do
my own CCL/SBCL implementation for my needs.

If my understanding is correct, the UIOP maintainers may wish to
emphasize the synchronous nature of UIOP:RUN-PROGRAM in its docstring.

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."