[ python-Bugs-1669637 ] Some Compiler Warnings on VC6
Bugs item #1669637, was opened at 2007-02-27 03:14 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 2 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: Some Compiler Warnings on VC6 Initial Comment: I got some warnings on VC6. Probably these are not so problematic, but anyway I reported. C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\winbase.h(53) : warning C4005: 'Yield' : macro was redefined. ..\..\Include\Python-ast.h(449) : Please check previous definition of 'Yield' E:\python-dev\release-maint25\Objects\intobject.c(994) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer. E:\python-dev\release-maint25\Objects\stringobject.c(859) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer. E:\python-dev\release-maint25\Modules\audioop.c(1263) : warning C4761: The base types of the actual and formal parameters of a function were different. The compiler converted the actual parameter to the type of the formal parameter. E:\python-dev\release-maint25\Modules\audioop.c(1331) : warning C4761: The base types of the actual and formal parameters of a function were different. The compiler converted the actual parameter to the type of the formal parameter. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-02-27 08:26 Message: Logged In: YES user_id=849994 Originator: NO I assume this is from the 2.5 maintenance branch. Which revision is it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669637 ] Some Compiler Warnings on VC6
Bugs item #1669637, was opened at 2007-02-27 12:14 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 2 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: Some Compiler Warnings on VC6 Initial Comment: I got some warnings on VC6. Probably these are not so problematic, but anyway I reported. C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\winbase.h(53) : warning C4005: 'Yield' : macro was redefined. ..\..\Include\Python-ast.h(449) : Please check previous definition of 'Yield' E:\python-dev\release-maint25\Objects\intobject.c(994) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer. E:\python-dev\release-maint25\Objects\stringobject.c(859) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer. E:\python-dev\release-maint25\Modules\audioop.c(1263) : warning C4761: The base types of the actual and formal parameters of a function were different. The compiler converted the actual parameter to the type of the formal parameter. E:\python-dev\release-maint25\Modules\audioop.c(1331) : warning C4761: The base types of the actual and formal parameters of a function were different. The compiler converted the actual parameter to the type of the formal parameter. -- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-02-27 22:30 Message: Logged In: YES user_id=1200846 Originator: YES Yes, Revision 53990 (Latest) -- Comment By: Georg Brandl (gbrandl) Date: 2007-02-27 17:26 Message: Logged In: YES user_id=849994 Originator: NO I assume this is from the 2.5 maintenance branch. Which revision is it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590864 ] import deadlocks when using PyObjC threads
Bugs item #1590864, was opened at 2006-11-05 18:06
Message generated for change (Comment added) made by kosuha
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Nobody/Anonymous (nobody)
Summary: import deadlocks when using PyObjC threads
Initial Comment:
When I use subprocess.py from a child thread, sometimes it deadlocks. I
determined that the new process is blocked during an import:
#0 0x90024427 in semaphore_wait_signal_trap ()
#1 0x90028414 in pthread_cond_wait ()
#2 0x004c77bf in PyThread_acquire_lock (lock=0x3189a0, waitflag=1)
at Python/thread_pthread.h:452
#3 0x004ae2a6 in lock_import () at Python/import.c:266
#4 0x004b24be in PyImport_ImportModuleLevel (name=0xaad74 "errno",
globals=0xbaed0, locals=0x502aa0, fromlist=0xc1378, level=-1) at
Python/import.c:2054
#5 0x0048d2e2 in builtin___import__ (self=0x0, args=0x53724c90,
kwds=0x0) at Python/bltinmodule.c:47
#6 0x0040decb in PyObject_Call (func=0xa94b8, arg=0x53724c90,
kw=0x0) at Objects/abstract.c:1860
and that the code in question is in os.py:
def _execvpe(file, args, env=None):
from errno import ENOENT, ENOTDIR
I think the problem is that since exec (the C function) hasn't yet been
called in the new process, it's inherited from the fork a lock that's already
held. The main process will eventually release its copy of the lock, but this
will not unlock it in the new process, so it deadlocks.
If I change os.py so that it imports the constants outside of
_execvpe, the new process no longer blocks in this way.
This is on Mac OS X 10.4.8.
--
Comment By: Kosuha (kosuha)
Date: 2007-02-27 18:54
Message:
Logged In: YES
user_id=1684258
Originator: NO
I confirm that problem with deadlock on execution of
PyImport_ImportModuleLevel exists. Here is a working example:
1) Python was embbeded with C++ application using Python for scripting
support:
--
PyThreadState * InitThreadScripting()
{
ASSERT_KOBOLD( g_pyMainThreadState );
// get the global lock
PyEval_AcquireLock();
// get a reference to the PyInterpreterState
PyInterpreterState * mainInterpreterState = g_pyMainThreadState->interp;
ASSERT_KOBOLD( mainInterpreterState );
// create a thread state object for this thread
PyThreadState * myThreadState = PyThreadState_New(mainInterpreterState);
// free the lock
PyEval_ReleaseLock();
return myThreadState;
}
-
void DeadLock()
{
Py_Initialize();
PyEval_InitThreads();
g_AiGlobals = new Py::Dict();
g_pyInterpState = PyInterpreterState_New();
// save a pointer to the main PyThreadState object
g_pyMainThreadState = PyThreadState_Get();
ASSERT_KOBOLD( g_pyMainThreadState );
// release the lock
PyEval_ReleaseLock();
g_pyWorldThreadState = InitThreadScripting();
// import sys
// sys.path.append ("./scripts")
//
PyObject*p = PyImport_ImportModuleEx ("sys", **g_AiGlobals, NULL, NULL);
Py::Module mod_sys (p);
Py::Listpath = mod_sys.getAttr ("path");
path.append (Py::String ("scripts"));
path.append (Py::String ("scripts/sys"));
path.append (Py::String ("../../scripts"));
path.append (Py::String ("../../scripts/sys"));
Py_XDECREF (p);
// HERE IT OCCURS //
Log.ScriptsSrc("Python", "Running startup python scripts...");
PyObject *p = PyImport_ImportModuleEx ("startup", **g_AiGlobals, NULL,
NULL); // <<< Here
if (reload) PyImport_ReloadModule (p);
Py::Module module (p);
Py_XDECREF (p);
}
Execution locks right on PyImport_ImportModuleEx.
Code from sturtup.py:
# This module is sturtup script.
# Here we are redirecting output and checking for server version.
import sys
from consts import * # Import of constants
import config as cfg # Import of configuration constants
reload(cfg)
#
class OurLogStdErr:
def write (self, txt):
printLog (txt, PRINT_ERROR)
#
class
[ python-Feature Requests-1670167 ] isinstance.__doc__ is somewhat irritating
Feature Requests item #1670167, was opened at 2007-02-27 18:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1670167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: René Fleschenberg (refl) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance.__doc__ is somewhat irritating Initial Comment: "With a type as second argument, return whether that is the object's type." That sentence does not really make sense, at least not for new-style classes. After reading that, one could expect that isinstance(1, object) would return False. I think the best thing would be to just drop that sentence from the doc string. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1670167&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
