Re: patch to support output synchronization under -j

[Tim Murphy]

File locking would be the exclusion mechanism with a shell
implementation, right?  With Talon we used a system semaphore with
timeout-wait semantics .  I would assume that one doesn't need it if
the code is in make since make can choose when to start and stop
reading from any particular file handle.

In Talon we don't use files but an expanding memory buffer instead. Is
this better/worse? I don't know.  Our huge builds don't really seem to
suffer memory shortages from this particular source.  I have seen a
commercial system that limits the total output - i.e. it won't take
more than X megabytes of output per task and in very large parallel
builds there are good reasons for having limits like this anyhow.

Regards,

Tim




On 14 April 2011 19:12, David Boyce <address@hidden> wrote:
> On Thu, Apr 14, 2011 at 1:48 PM, Eli Zaretskii <address@hidden> wrote:
>> David, can you explain why you needed to lock the files?  Also, what
>> region(s) of the file you are locking?  fcntl with F_WRLCK won't work
>> on Windows, so the question is how to emulate it.
>
> I was about to write this up but I see Paul beat me to it ...
>
>> Finally, I'd suggest that the system-dependent portions of sync_output
>> be factored out into a separate function, so that the Windows port
>> could have its own implementation without infesting job.c with yet
>> another bunch of #ifdef's.
>
> Agree. Ifdef bad. Just wanted to see if the feature would be favorably
> looked on first. I can't actually do the Windows etc ports but I could
> certainly refactor it with stubs.
>
> David
>
> _______________________________________________
> 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/