Re: [gentoo-alt] multilib / multijob / parallel build problem

[Greg Turner]

Alan wrote:
> - redirect_alloc_fd mj_control_fd "${pipe}"
> + redirect_alloc_fd mj_write_fd "${pipe}"
> + redirect_alloc_fd mj_read_fd "${pipe}"

The one thing I'd be looking to verify is that there's no race where
where the reader must block before the writer starts producing data.

You could test that hypothesis by sleeping for a while right before
the reader starts listening.

If that were the case -- I kinda suspect it is -- then unfortunately,
I think the writer has to spin, waiting for the reader to block... not
a pretty situation, so let's hope I'm confused.

-gmt

On Sun, Oct 6, 2013 at 6:55 AM, Alan Hourihane <alanh@×××××××××××.uk> wrote:
> On 10/06/13 00:52, Greg Turner wrote:
>>
>> On Sat, Oct 5, 2013 at 4:42 PM, Alan Hourihane <alanh@×××××××××××.uk>
>> wrote:
>>>
>>>  From what I can see it's down to bi-directional read/write on a FIFO.
>>>
>>> Typically a FIFO expects a reader and a writer (it's just a filesystem
>>> PIPE).
>>> Therefore we should be using two file descriptors, one for read and one
>>> for write. Not one file descriptor and using read/write. That's the
>>> Linux'ism
>>> we're talking about here.
>>
>> Yes, ACK that entirely.  However an argument could be made that
>> because BSD, Linux, and everything else with any significant user-base
>> have arrived at sufficiently similar non-POSIX behaviors, Gentoo's
>> able to get away with it.  The matter has been discussed, and a
>> consensus was reached among the devs that it was an OK compromise.
>>
>> I think if you re-coded the multiprocessing stuff to work the same,
>> without exploiting this platform quirk or making a big mess of the
>> code, and posted your patches to your bug (and a separate one for
>> portage) you could probably get your patches in.  But just filing a
>> bug and expecting someone else to fix it is probably not going to
>> work, IMO.
>>
> Fixed for my OS, and it still works on Linux.
>
> Patches uploaded.
>
> Alan.
>