--9axOBMfiLLqytT81
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Before replying to other posts, as expected, using append(1) allowed me to
use NBUILDJOBS=3D4 successfully.



On Thu, Jun 06, 2002 at 12:17:18PM +0100, Ben Harris wrote:

> libnbcompat emulates flock(2) using POSIX fcntl() locks, whose existence I
> think it's reasonably to rely on.

Oh, cool. Excellent, even.


> OTOH, I don't like your interface.  What's wrong with making append(1) ha=
ve
> the same behaviour as cat(1) (read from files in argv or stdin, write to
> stdout)?

Can you lock stdout usefully? If you redirect stdout to a file, having lock=
ed
it, is the file locked?

If so, then I would prefer this, and will be happy to implement it that
way.  I'd want to know that that works consistently across filesystems,
though, and I'd want to understand what it implied for pipes and such, as
opposed to redirections.


 Come to that, how about something like:
>=20
> main(int argc, char **argv)
> {
>=20
> 	flock(STDOUT_FILENO, LOCK_EX);
> 	if (!fork())
> 		execvp("cat", argv);
> 	wait();
> 	flock(STDOUT_FILENO, LOCK_UN);
> 	return 0;
> }

If locking stdout does what you're suggesting, I guess that would be
completely sufficient.


On Thu, Jun 06, 2002 at 01:20:03PM +0100, David Laight wrote:

> Also you doing a rather global lock.  IIRC the header file (or was it
> timezone) parts of the build add lots of records using find.  Your
> 'append' program will lock the METALOG file for the duration of the find
> - stopping the parallel build in its tracks.

Yes. This doesn't bother me a huge amount, given that it will explicitly
not be slower than a -j 1 build. It SHOULD be faster... The finds and such
won't be made linear - they will still happen concurrently. It's simply the
writing to METALOG that will happen atomically.


> Would it be more reasonable to just rely on O_APPEND - and do a
> single write() call for each entry?

I wouldn't trust it. I'd want to see explicit locking done in any event.


> OTOH the append() program could use fgets() fputs()....

This is a possibility. The downside is that I despite deciding on an
arbitrary limit for line sizes. This could be done more dynamically, either
with fparseln or (better) with something simpler and homebrewed, but I'm
sort of a fan of doing it chunk-by-chunk... Either way. If it were done
line by line, it could of course only choose to lock immediately prior to
writing each line, and unlocking immediately thereafter.

For now, I'm going to be content with having a local solution that works
nicely. :)

--=20
Mason Loring Bliss   mason@acheron.middleboro.ma.us   Ewige Blumenkraft!
https://www.deadsexy.org/  awake ? sleep : random() & 2 ? dream : sleep;

--9axOBMfiLLqytT81
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE8/8cEykMMY715wXIRAsRSAKDtBP94UhuWRwTuzdrk4ZK28DHFEACeJj8o
MhtGpV/+tvsISCGfg6FLOkE=
=cQW4
-----END PGP SIGNATURE-----

--9axOBMfiLLqytT81--