From: Simon Mika <smika@hx.se>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] emerge feature request: Downloads managed by lock file system
Date: Sat, 7 Feb 2004 18:04:18 +0100 [thread overview]
Message-ID: <20040207170418.GA558@hx.se> (raw)
In-Reply-To: <200402071318.47224.thomas@horsten.com>
Although I have a computer that is a bit slower I have the similiar problem.
Downloading does not consume much processorpower and athor machine
resources. But compiling does need a lot. Wy don't use always use 2
parallell processes, one that downloads, and one that compiles. The
compiling process would still need to be synced with the downloading, but
that should not be too hard to implement with some semaphore or similiar
solution.
/Simon Mika
On Sat, Feb 07, 2004 at 01:18:47PM +0000, Thomas Horsten wrote:
> Hi,
>
> I have a request for an emerge feature that I think would be useful for a lot
> of people.
>
> I have quite a fast machine with RAID and 3GHz CPU, and only a 512kbit/s
> Internet connection. When I do an "emerge -u world" most of the time actually
> goes by waiting for packages to download. For most ebuilds, It takes roughly
> the same time to download as to compile.
>
> So to speed up my builds, I usually start an "emerge -f -u world". Once the
> first couple of packages have downloaded I then start an "emerge -u world" in
> another shell.
>
> This works great as long as the fetcher process is ahead of the builder
> process. But if some packages are built too quickly, the builder process
> catches up. It then starts downloading the same file as the downloader
> process, resuming from wherever the downloader had gotten to, so now two
> downloaders are writing to the same file (waste of bandwidth and a possible
> source of corrupted archives).
>
> What I suggest is that emerge will put a lockfile in place when it's
> downloading a file, eg. "name-of-package.tar.bz2.lock", or by using fcntl
> locks. Then if the "builder" catches up, and finds the output file is already
> open, it waits on the lock for the download to complete and then continues
> unpacking after that.
>
> I already love gentoo and the portage system, it's by far the best available,
> but adding this feature would make it even better IMHO.
>
> Regards,
>
> Thomas
>
>
> --
> gentoo-portage-dev@gentoo.org mailing list
>
--
gentoo-portage-dev@gentoo.org mailing list
next prev parent reply other threads:[~2004-02-07 17:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-07 13:18 [gentoo-portage-dev] emerge feature request: Downloads managed by lock file system Thomas Horsten
2004-02-07 17:04 ` Simon Mika [this message]
2004-02-07 17:17 ` Sven Vermeulen
2004-02-07 22:07 ` Jeff Smelser
2004-02-08 0:59 ` Thomas Horsten
2004-03-28 0:21 ` Roman Gaufman
2004-03-29 14:39 ` [gentoo-portage-dev] Downloading while compiling - FETCHCOMMAND inside Roman Gaufman
2004-03-29 18:10 ` Wiebel
2004-03-29 19:35 ` Roman Gaufman
2004-03-30 0:37 ` Wiebel
2004-04-04 11:38 ` Brian Harring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040207170418.GA558@hx.se \
--to=smika@hx.se \
--cc=gentoo-portage-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox