Re: patch to support output synchronization under -j

[Tim Murphy]

Ok,

To prevent any kind of deadlock you sort of want to empty everything
the stderr and stdout pipe buffers may contain.

It is conceivable that the stdout pipe might contain two lines of text
and stderr pipe might contain 1 by the time your select statement (or
waitformultipleobjects) has woken up.

How do you know what order they should be in in the output?  SeS, SSe
or eSS?  So one theory goes -ah forget it.

Regards

Tim

On 14 April 2011 20:46, Tim Murphy <address@hidden> wrote:
> That was a confused email - apologies.  I will rethink it and return. :-)
>
> On 14 April 2011 20:43, Tim Murphy <address@hidden> wrote:
>> ---------- Forwarded message ----------
>> From: Tim Murphy <address@hidden>
>> Date: 14 April 2011 20:43
>> Subject: Re: patch to support output synchronization under -j
>> To: address@hidden
>>
>>
>> The reason for splitting stderr and stdout is to do with deadlock and
>> reading pipes. IIRC.  e.g. blocking on a read to stderr which will
>> never return because the process is stuck waiting for you to read from
>> it's stdout.  I think it's all easier on an os where you can create
>> ptys (is that the term?)  i.e. fake "consoles" to which stdout and
>> stderr are both attached.
>>
>>  I am going to be lazy and let someone else justify this or shoot it
>> down.  Perhaps I will remember why I got into trouble with it a long
>> time ago.
>>
>> In practice the non-interleaving is actually nice in examples I've
>> seen because the context is obvious from the error message itself
>> (otherwise its' a crap error message and needs updating) and the
>> division makes it  a little easier to scan for error messages
>> automatically.
>>
>> It's more of a problem where you're running a task that executes some
>> long sub-build.
>>
>> Regards,
>>
>> Tim
>>
>>
>> On 14 April 2011 20:16, Paul Smith <address@hidden> wrote:
>>> On Thu, 2011-04-14 at 14:08 -0400, David Boyce wrote:
>>>> On Thu, Apr 14, 2011 at 1:29 PM, Paul Smith <address@hidden> wrote:
>>>> > One example: I think saving stdout and stderr to different files and
>>>> > then printing them separately is problematic; consider if your recipe
>>>> > prints lots of information lines, with errors (to stdout) interspersed.
>>>> > If you throw all the errors to the end you lose a lot of context.
>>>>
>>>> The reason is that the SHELL variable is used not only for recipes but
>>>> also for the $(shell) function. Intermingling stdout and stderr in the
>>>> result of $(shell) is just disastrously wrong (as I found in the first
>>>> iteration of syncsh). I spent some time trying to find a way to
>>>> determine, from inside a child shell, whether we were forked by a
>>>> recipe or by $(shell) but could find no reliable way. Thus syncsh was
>>>> forced to keep them in separate files. Since $(shell) invocations are
>>>> not "jobs" according to make's process model there's no need for them
>>>> to participate in synchronization at all, so it may be that within
>>>> make there's a way to only sync on recipes which in turn would allow
>>>> 2>&1.
>>>
>>> Your latter statement is absolutely correct: it's wrong for $(shell ...)
>>> to synchronize.  Shell function output is captured by make, not printed
>>> to stdout, so synchronizing it doesn't make much sense.
>>>
>>>> Of course, either way some context is lost. If you put both into one
>>>> temp file you lose track of which was which; if you keep them in
>>>> separate files you lose ordering instead. So it becomes a matter of
>>>> taste, or perhaps an option though that seems like a bit too much to
>>>> me.
>>>
>>> I agree that adding an option seems like a lot.
>>>
>>> I think it's more important to maintain ordering of stdout/stderr than
>>> it is to allow individual redirection.
>>>
>>> However, you could do both with some heuristics.  Hm.  Maybe not.  I was
>>> going to say you could merge them if stdout and stderr were going to the
>>> same tty or file, but I don't think there's any good way in UNIX to know
>>> whether two file descriptors are pointing at the same file/device.  Hrm.
>>> In Linux you can find out via /proc but that's a pretty special case.
>>>
>>> --
>>> -------------------------------------------------------------------------------
>>>  Paul D. Smith <address@hidden>          Find some GNU make tips at:
>>>  http://www.gnu.org                      http://make.mad-scientist.net
>>>  "Please remain calm...I may be mad, but I am a professional." --Mad 
>>> Scientist
>>>
>>>
>>> _______________________________________________
>>> Bug-make mailing list
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/bug-make
>>>
>>
>>
>>
>> --
>> You could help some brave and decent people to have access to
>> uncensored news by making a donation at:
>>
>> http://www.thezimbabwean.co.uk/
>>
>>
>>
>> --
>> You could help some brave and decent people to have access to
>> uncensored news by making a donation at:
>>
>> http://www.thezimbabwean.co.uk/
>>
>
>
>
> --
> You could help some brave and decent people to have access to
> uncensored news by making a donation at:
>
> http://www.thezimbabwean.co.uk/
>



-- 
You could help some brave and decent people to have access to
uncensored news by making a donation at:

http://www.thezimbabwean.co.uk/