| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
git-svn-id: http://opkg.googlecode.com/svn/trunk@310 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
| |
git-svn-id: http://opkg.googlecode.com/svn/trunk@306 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
| |
- Don't try to free() memory in a different process!
- Move the function to a more appropriate file.
- Fix error messages while here.
git-svn-id: http://opkg.googlecode.com/svn/trunk@305 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
| |
Waiting for the patch fixing bugs.
git-svn-id: http://opkg.googlecode.com/svn/trunk@192 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
----------
This patchset updates the libbb stuff to use a vfork() version of
gz_open, called gzvopen. This is done because a standard fork will
duplicate the entire address space. This will invoke the OOM
(out of memory) killer on small-memory machines, because most often
by the time we unzip any package, we've read the entire package
database into memory already. By using vfork() and immediatly
execing the external gunzip utility, we avoid the need to clone the
entire address space.
Yes, this is actually **LESS** efficient than the original way!
But there is no way to (currently) dodge the OOM killer on a
per-process basis, so the alternatives are to either change the
OOM killer behavior system-wide, or to use this workaround.
Mike Westerhof, Dec 2008
git-svn-id: http://opkg.googlecode.com/svn/trunk@190 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
|
|
git-svn-id: http://opkg.googlecode.com/svn/trunk@3 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
