upgrading/installing in a background process

[Clemens Lang]

----- On 5 May, 2015, at 14:33, René J.V. Bertin rjvbertin at gmail.com wrote:

> I think there's really no reason to allow the flush command to abort in this
> case. The alternative would be to do the tcl equivalent of
> `if( isatty(stdout) )` because the flush probably makes sense only when stdout
> is connected to a terminal ...

Fix one of the occurrences of flush, and MacPorts will fail on the next. Even
adding isatty(stdout) won't change a thing in your "use case": We already check
for stdout being a TTY for the progress bar code, but if it was a TTY when you
started the command and gets closed later on you will get the same problem. Did
you even test this change?

In the end, running MacPorts without a connected output channel is currently not
supported. Since the workarounds for this are trivial, I won't invest any time to
make it supported.


> How often is this flush executed, and what percentage of the corresponding
> progress indication is never sent to a terminal?

It's executed once per dot printed during dependency calculation. As you can see
from the code, the flush is necessary because the dot would otherwise not be
visible on a users terminal until the process was complete.

All of the progress indication is sent to a terminal, unless you do not have a
terminal attached to MacPorts' stdout (which is not a very common use case). In
most cases where MacPorts' stdout is not a terminal, it still exists (e.g. a file
or just /dev/null), in which case the flush is superfluous, but harmless,
especially when compared to the compile times of some of our ports.


> Flushing can be expensive (very, even), and *could* be part of what delays
> build/upgrade commands for ports that have a lot of dependencies (the VM in
> question takes almost a minute to check all dependencies of port:kde4-workspace
> before it starts fetching/extracting/patching/etc).

That's because it executes a *lot* of Portfiles. Flushing stdout has nothing to do
with it. Please, remember Knuth:

  "We should forget about small efficiencies, say about 97% of the time: premature
   optimization is the root of all evil."

-- 
Clemens Lang