Nick Coghlan wrote:
> Broadening the ifdef to cover all posix systems rather than just AIX
> might be the right thing to do.
As I said: I doubt it is the right thing to do. Instead, the lock
should get released in the child process if it is held at the
point of the fork.
I agree that we should f
Yair Chuchem wrote:
> Rotem should simply avoid to fork() in the toplevel code of a module.
>
>
> this is not what happened.
> we called subprocess which itself called fork.
Ok - but are you calling subprocess in the context of code that is just
being imported? Or is the caller of the code t
Rotem Yaari wrote:
>> Rotem should simply avoid to fork() in the toplevel code of a module.
>>
>
> That's exactly the problem - the fork is not done at the module level,
> and the reason for the deadlock is imports inside functions performed
> by various library functions.
> This can happen virtua
[M.-A. Lemburg]
>>> Could you please make this fix apply only on Solaris,
>>> e.g. using an #ifdef ?!
[Martin v. Löwis]
>> That shouldn't be done. The code, as it was before, had
>> undefined behaviour in C. With the fix, it is now correct.
[Marc-Andre]
> I don't understand - what's undefined in:
On 5/11/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote:
> If for Python-3000 similar it will be shown concerning types
> str(), int(), complex() and so on, and the type of exceptions
> will strongly vary, it will make problematic redefinition of
> behavior of function of sorting.
I don't see
Guido van Rossum wrote:
> On 5/11/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote:
>> If for Python-3000 similar it will be shown concerning types
>> str(), int(), complex() and so on, and the type of exceptions
>> will strongly vary, it will make problematic redefinition of
>> behavior of fun
Hi,
This patch submitted in March allows Python trunk to be built using MSVC 6:
http://sourceforge.net/tracker/index.php?func=detail&aid=1457736&group_id=5470&atid=305470
It is not my patch but I am quite interested because the code changes are
also required to build with MS eMbedded Visual C++
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> Well, the strings and integers count twice: once in the module
>> namespace and once in the errorcode dictionary.
>
> That shouldn't be the case: the strings are interned (as they
> are identifier-like), so you have the very same string object
> in
Martin v. Löwis wrote:
> So if the the import lock was held during the fork call, the new thread
> will hold the import lock of the new process, and subsequent imports
> will block.
> However, then the problem is not with the execve implementation, but
> with the fact that the import lock was held
Richard Jones wrote:
> I just built 2.5 SVN on my OS X 10.4 laptop. I ran into the missing
> sys/statvfs.h problem that has been reported here in the past. To
> solve the problem I needed to upgrade my XCode install from 1.1 to
> 2.2.1 - the missing header files (there was actually a whole lo
10 matches
Mail list logo
