Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Message-ID: <047501c4636f$d4c81aa0$40efea43@sybase.com>
From: "Adam R. B. Jack" <ajack@trysybase.com>
To: "Gump code and data" <general@gump.apache.org>
References: <00df01c45eaa$ebbdeb00$531ee641@sybase.com>
 <40E57390.9090206@gmx.de> <02c301c46046$4de77c50$c01ee641@sybase.com>
Subject: Re: Multithreading the updates
Date: Tue, 6 Jul 2004 09:26:57 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> The code doesn't appear to be breaking (despite Python not locking in base
> classes like lists, and the Gump code not locking all that it might). I
> tried doing a Google search for locking in Python, and really found little
> "street wise" information. I found some updates from a Mr Stein (a gent,
not
> a gazillion miles from ASF ;-) but little that really told me what the
risks
> are w/ running large pieces of Python in separate threads. I guess we suck
> it and see.

We'll sucked ... and it sucked. ;-) Something was not playing nicely.

I believe the issue is likely to do with the fact that to launch a new
executable (CVS|SVN or whatever) Python Gump currently uses process global
CD and process global ENV modifications, then spawn's via system(). Clearly
that this is not thread safe. Basically I've always hated this portion of
the code, just never had chance/incentive to re-write it to those complex
alternatives. This might be the time.

Just giving a heads up as to why I disabled threads on the JDK1.5 and
gump.try servers...

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org