Joachim König wrote:
> So one would have to set up the application specific packages before
> running the application, but the
> whole clutter of uncounted versions of the same package in one directory
> could go away. The
> "drawback" of this approach would be, that the same version of a package
>
On Thu, May 18, 2006 at 3:02 PM, "Martin v. Löwis" wrote:
>
> Right. With some googling, I found that one solution is pthread_atexit:
> a pthread_atexit handler is a triple (before, in_parent, in_child).
> You set it to (acquire, release, release).
Did you mean pthread_atfork() ?
> When somebody
Thomas Wouters wrote:
> Picking up a rather old discussion... We encountered this bug at Google
> and I'm now "incentivized" to fix it.
>
> For a short recap: Python has an import lock that prevents more than one
> thread from doing an import at any given time. However, unlike most of
> the locks
On Thu, May 18, 2006 at 20:02, "Martin v. Löwis" wrote:
> Nick Coghlan wrote:
> > And if I understand it correctly, it falls under the category that
> > waiting for another thread while holding the import lock is a *really*
> > bad idea from a thread safety point of view.
> >
> > The thing with t
P.J. Eby wrote:
At 05:16 PM 7/15/2009 +0200, Joachim König wrote:
f you have m different versions of n packages then
you could have n**m different combinations for an application so you
need a
possiblilty to select one combination from n**m possible ones at
application
startup time. Is this r
