On Wed, 24 Mar 2010, Fredrik Kuivinen wrote:

quoted text
> On Wed, Mar 24, 2010 at 00:50, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Tue, 23 Mar 2010, Fredrik Kuivinen wrote:
> >
> >> On Tue, Mar 23, 2010 at 19:43, Shawn O. Pearce <spearce@spearce.org> 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