Date: Tue, 9 Nov 2010 06:00:29 GMT From: Andriy Gapon <avg@freebsd.org> To: gnome@FreeBSD.org Subject: Re: ports/151725: sysutils/hal: hald fails to start with dbus-1.4 Message-ID: <201011090600.oA960TsD065864@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/151725; it has been noted by GNATS.
From: Andriy Gapon <avg@freebsd.org>
To: Joe Marcus Clarke <marcus@freebsd.org>
Cc: Kevin Oberman <oberman@es.net>, gnome@freebsd.org,
bug-followup@freebsd.org
Subject: Re: ports/151725: sysutils/hal: hald fails to start with dbus-1.4
Date: Tue, 09 Nov 2010 07:54:32 +0200
on 09/11/2010 07:52 Andriy Gapon said the following:
> on 09/11/2010 07:47 Joe Marcus Clarke said the following:
>> On 11/9/10 12:36 AM, Andriy Gapon wrote:
>>> on 09/11/2010 02:14 Kevin Oberman said the following:
>>>> I'll try this as soon as I can. I'm not too sure that it will happen as
>>>> I think that this is somehow timing related. I suspect that the entry is
>>>> disappearing too quickly with 1.4 in some cases but is not a problem
>>>> with 1.2. Perhaps some optimization?
>>>>
>>>> I suggest this because on at least rare occasion, 1.4 did run
>>>> successfully, not because I have any clue what was happening under the
>>>> covers.
>>>
>>> I guess that I already explained this part.
>>> The problem happened because we tried to write something (even if it's just zero
>>> sized something) into stdin of a child process that already exited.
>>> Sometimes the child process was quicker, sometimes the parent process was
>>> quicker, hence the non-determinism.
>>>
>>
>> Ah, I missed that. I wonder if it would be safer then to ignore SIGPIPE
>> around the write block.
>
> Maybe.
Actually, please read the above as "probably no".
If a child process that is supposed to get input would crash, then such a change
would obfuscate diagnostics.
> But not calling write(2) when we don't have anything to write (zero
> length) also looks like a good solution (for me personally).
>
> My point is: zero-sized write in nothing but testing OS implementation details
> of handling zero-sized writes, it doesn't perform any useful function.
> OTOH, if a child process is supposed to get any actual input, then it won't exit
> prematurely, but would block reading from its stdin until the input arrives.
>
> But I think I am starting to repeat what I have already wrote before.
>
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011090600.oA960TsD065864>