Re: lockf in installworld -- not a good idea

On Fri, 29 Sep 2006, Ruslan Ermilov wrote:

>>> I don't know of a better fix.  Another approach is that mentioned in the 
>>> commit log and used by NetBSD.  I tried it, and it was very fragile -- it 
>>> could easily leave the temporary file around, and that would stuck forever 
>>> another instances.
>>>
>>> The problem at hand is that multiple instances of install-info(1) are 
>>> attempting to write to the ${DESTDIR}/usr/share/info/dir file. If you have 
>>> a better idea, don't hesitate to let me know.  I'd very much like to get 
>>> rid of that as well.
>>
>> The basic problem here is that install-info doesn't support parallelism. 
>> Sounds like we just need to accept that and therefore accept that we don't 
>> support doing installworld with the -j argument.  A middle-ground solution 
>> would be to only use lockf if -j is used.
>>
> How could it support parallelism without using lockf(3) or equivalent? I'd 
> be happy to hack install-info(1) if there's a way.

Yes, that's why it's the basic problem. :-)  The problem is the way info works 
-- that it uses a shared file for a global table of contents, rather than 
constructing it from a set of independent files once.  Is there any way to 
generate the entries in the directory incrementally in different files, then 
combine them all at the end once?  I.e., like we do with the man page apropos 
database -- we build all the elements independently, which is parallelizable, 
and then once at the end once it's all done, we build the single central 
database.

> A middle-ground solution was easy to implement, and I have a patch for it if 
> a more clean solution couldn't be found.

I'd like to see that in the tree in the near future.  If nothing else, it will 
speed up installworld in the non-j case, probably measurably (although I've 
not measured it :-).

Robert N M Watson
Computer Laboratory
University of Cambridge