[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [bug #33138] .PARLLELSYNC enhancement with patch

From: Tim Murphy
Subject: Re: Fwd: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Fri, 26 Apr 2013 09:05:18 +0100

On 25 April 2013 20:06, Eli Zaretskii <address@hidden> wrote:
> Date: Thu, 25 Apr 2013 19:36:28 +0100
> From: Tim Murphy <address@hidden>
> Cc: "address@hidden" <address@hidden>
> 1)  sem_timedwait() in posix lets you timeout so in a big build when
> something crashes or just sits around, there is at least the option of
> printing an error message or giving up on locking from that point on which
> is a bit of a godsend if it happens overnight and there's no-one to restart
> the build.

How much would you use for the timeout, though?  A sub-Make could
legitimately run for a very long time, depending on what's in the

FWIW, I currently let Make wait forever for the mutex.

It's a horrible question and no answer makes people happy.   It's a kind of exceedingly blunt tool that you only use because there is no other.  I have seen systems where the child process watches stdio/stderr activity and times out if there isn't any and that just gets into trouble with processes that run long and silent.

On the other hand, having your 24-hour build hang after 2 hours when you have a lot of people waiting on the result is a sort of costly thing.  Even if you accept that a lot of the build will be broken, there is still a lot of feedback to get from the parts which should be able to complete - errors and warnings, unit tests and so on - that people can take action on while the build is being fixed.

So timeouts have to be configurable by users who can set whatever they think is the least bad compromise in their particular case.



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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]