On Wed, 24 Mar 2010, Fredrik Kuivinen wrote: > On Wed, Mar 24, 2010 at 00:50, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > On Tue, 23 Mar 2010, Fredrik Kuivinen wrote: > > > >> On Tue, Mar 23, 2010 at 19:43, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > >> > If that is what we are doing, disabling the release of pack windows > >> > when malloc fails, why can't we do that all of the time? > >> > >> The idea was that most git programs are single threaded, so they can > >> still benefit from releasing the pack windows when they are low on > >> memory. > > > > This is bobus. The Git program using the most memory is probably > > pack-objects and it is threaded. Most single-threaded programs don't > > use close to as much memory. > > Ok, you are right. But xmalloc/xrealloc cannot be used in multiple > threads simultaneously without some serialization. > > For example, I think there are some potential race conditions in the > pack-objects code. In the threaded code we have the following call > chains leading to xcalloc, xmalloc, and xrealloc: > > find_deltas -> xcalloc > find_deltas -> do_compress -> xmalloc > find_deltas -> try_delta -> xrealloc > find_deltas -> try_delta -> read_sha1_file -> ... -> xmalloc (called > with read_lock held, but it can still race with the other calls) > > As far as I can see there is no serialization between these calls. True. We already have a problem. This is nasty. Nicolas