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 <david.s.bo...@gmail.com> wrote: > On Thu, Apr 14, 2011 at 1:48 PM, Eli Zaretskii <e...@gnu.org> 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 > Bug-make@gnu.org > 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/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
