[issue877121] configure detects incorrect compiler optimization
John Levon added the comment: That's a little abrupt. Whilst it would be nice if the compiler had a correct return value, it occurs with multiple compilers, and I pointed you to a suitable workaround Python could employ. Even if Studio gets fixed, there are previous releases out there for a long time. -- ___ Python tracker <http://bugs.python.org/issue877121> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue877121] configure detects incorrect compiler optimization
John Levon added the comment: Even worse, a nasty hack was added just for Intel's compiler as seen in http://bugs.python.org/issue1162001 -- ___ Python tracker <http://bugs.python.org/issue877121> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
John Levon added the comment: Anatoly, see above. We have done exactly that. (Honestly, when I first wrote the changes, I saw them as too hacky to ever be accepted upstream). This name change seems frivolous and will indeed break existing scripts. -- ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10201] Fix building of socket module under Solaris
John Levon added the comment: This is not a bug in Solaris - the interfaces Python is trying to use are not standardized. (It's a reasonable RFE for Solaris to fully support these, though - I'll follow up on that.) WRT the patch, at least the PACKET_* defined would be better done via a specific guard (#ifdef PACKET_LOOPBACK ...). -- ___ Python tracker <http://bugs.python.org/issue10201> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
John Levon added the comment: The posted patch: better if the PACKET_* tests were just at the two missing ones rather than removing all of the ones that are actually there like PACKET_OUTGOING. -- ___ Python tracker <http://bugs.python.org/issue8852> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
John Levon added the comment: configure.in has: AC_MSG_RESULT([$with_dtrace]) ... AC_MSG_RESULT($with_dtrace) Why twice? It looks confusing. -- ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11016] Add S_ISDOOR to the stat module
John Levon added the comment: Jesus, yes, it's totally possible that POSIX might define: (stat.S_IFSOCK + stat.S_IFIFO) to mean something other than S_IDOOR. However, the POSIX committee is always careful to respect existing usage. It's vanishingly unlikely that any attempt to do this would actually happen, since it would be obviously unimplementable on the most popular UNIX (namely Solaris). -- ___ Python tracker <http://bugs.python.org/issue11016> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7946] Convoy effect with I/O bound threads and New GIL
Changes by John Levon : -- nosy: +movement ___ Python tracker <http://bugs.python.org/issue7946> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4434] Embedding into a shared library fails
Changes by John Levon <[EMAIL PROTECTED]>: -- nosy: +movement ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4434] Embedding into a shared library fails
John Levon <[EMAIL PROTECTED]> added the comment: Besides, .so files should always declare their dependencies. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4434] Embedding into a shared library fails
John Levon <[EMAIL PROTECTED]> added the comment: If Ubuntu wants to deliver a static libpython, it also needs to deliver static versions of the Python modules, or accept that they're not usable from a static libpython. It makes no sense at all to mix libpython.a with these .so files. Many of them declare dynamic dependencies on stuff like libkrb5.so or libsqlite3.so. I can't conceive of a scenario where you need a static libpython AND you're OK with both dlopen() of the Python modules and any of its dynamic dependencies. What is this case? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked
John Levon added the comment: This issue also affects Solaris (and in particular xend is broken). Is there a reason bamby's fix isn't yet applied? -- nosy: +movement title: signals in thread problem -> signals not always delivered to main thread, since other threads have the signal unmasked ___ Python tracker <http://bugs.python.org/issue1975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked
John Levon added the comment: Yes, Python guarantees the behaviour under discussion: http://docs.python.org/library/signal.html ___ Python tracker <http://bugs.python.org/issue1975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Changes by John Levon : -- nosy: +movement ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
John Levon added the comment: I haven't seen "shorter than expected" message before, sounds like a Mac OS X specific thing. As for never getting any probes out, this is where it gets fun. Debugging this is very tricky indeed: it involves you dropping into the kernel debugger and looking at the interpreter's state. Most likely, the compiler is doing something different with the relevant Python functions, causing the logic in the DTrace ustack probe to fail. I don't even know how the Apple guys debug this sort of thing, but they'd definitely need to be involved. ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4609] Allow use of > 256 FD's on solaris in 32 bit mode
Changes by John Levon : -- nosy: +movement ___ Python tracker <http://bugs.python.org/issue4609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3928] os.mknod missing on Solaris
Changes by John Levon : -- nosy: +movement ___ Python tracker <http://bugs.python.org/issue3928> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared
Changes by John Levon : -- nosy: +movement ___ Python tracker <http://bugs.python.org/issue3265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1759169] clean up Solaris port and allow C99 extension modules
John Levon added the comment: Just came across this bug. _XOPEN_SOURCE_EXTENDED isn't the only sticking point here: neither XPG3 nor XPG4 have C99 either: _XOPEN_SOURCE (at least with a value below 600) is definitely wrong. To quote the header: "346 * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application 347 * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, 348 * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 349 * or a POSIX.1-2001 application with anything other than a c99 or later 350 * compiler. Therefore, we force an error in both cases. " Martin, you are correct that these macros choose particular semantics in some cases. However, this does not change my point. It is a fact that specifying these macros mean what I describe, and that doing so causes significant problems in compiling Python extensions. We may wish it to be different, but it's not. As Solaris has only ever moved towards the POSIX spec, __EXTENSIONS__ is the right thing to always specify here: it enables everything "modern" that you need (*including* POSIX semantics - check that signal.h on Solaris 9 for __EXTENSIONS__), without making any claims about conformity of Python extensions (which it it is not pyconfig.h's place to say!). I hope that's a clearer explanation of why Python is doing the wrong thing both theoretically and practically for Solaris. -- nosy: +movement ___ Python tracker <http://bugs.python.org/issue1759169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue877121] configure detects incorrect compiler optimization
John Levon added the comment: Yep, this is an annoying misfeature of Sun Studio. There is no way to affect this behaviour. There is a Sun Studio bug filed for this (-errwarn should affect this behaviour, but it doesn't). Here's some example m4 that libvirt uses to check this case properly: AC_DEFUN([gl_COMPILER_FLAGS], [AC_MSG_CHECKING(whether compiler accepts $1) AC_SUBST(COMPILER_FLAGS) ac_save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS $1" AC_TRY_LINK([], [], has_option=yes, has_option=no,) echo 'int x;' >conftest.c $CC $CFLAGS -c conftest.c 2>conftest.err ret=$? if test $ret != 0 -o -s conftest.err -o $has_option = "no"; then AC_MSG_RESULT(no) else AC_MSG_RESULT(yes) COMPILER_FLAGS="$COMPILER_FLAGS $1" fi CFLAGS="$ac_save_CFLAGS" rm -f conftest* ]) -- nosy: +movement ___ Python tracker <http://bugs.python.org/issue877121> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue976613] socket timeout problems on Solaris
Changes by John Levon : -- nosy: +movement ___ Python tracker <http://bugs.python.org/issue976613> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1759169] clean up Solaris port and allow C99 extension modules
John Levon added the comment: Python should define *only* __EXTENSIONS__, not the others, as Zooko already mentioned, for the reasons he mentioned. I'm not sure how you got a different impression from what I or he said. ___ Python tracker <http://bugs.python.org/issue1759169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1759169] clean up Solaris port and allow C99 extension modules
John Levon added the comment: Zooko, the patches are available here: http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/ > Then you were arguing that defining _XOPEN_SOURCE is wrong if the value Actually, I was saying that below that value simply won't work for many extensions. > What about setting the value to 600 or larger? Is that also wrong, > and if so, why? Practically: I don't know for sure about a larger value. As it is presumably very close to POSIX, it shouldn't significantly harm the ability to compile stuff. I can't say for sure. However, specifying _XOPEN_SOURCE is still unnecessary I believe. Theoretically: yes, it's wrong for Python to claim that all extensions are compliant to a particular XPG environment. If it helps, Martin, I can put you in touch with our standards expert. I'm far from such, so this might help assuage your doubts? ___ Python tracker <http://bugs.python.org/issue1759169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37790] subprocess.Popen() is extremely slow
Change by John Levon : -- nosy: +movement ___ Python tracker <https://bugs.python.org/issue37790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37790] subprocess.Popen() is extremely slow (with close_fds=True which is the default) on Illumos
John Levon added the comment: closefrom() is on both Solaris and illumos too - and might even have originated there as an API - so if that's the issue, it should be trivially fixable -- ___ Python tracker <https://bugs.python.org/issue37790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37790] subprocess.Popen() is sometimes slower in python3 under illumos
John Levon added the comment:
I checked, and the supposition this is due to lack of closefrom() doesn't seem
to be correct. Running the test case and looking at 'truss' output, there is no
large number of close() that one would expect if this was the issue.
I don't see Alexander's 2-time speedup however:
root@piano:/export/src/cpython# /export/python3/bin/python3 ./1.py
11.679689645767212
root@piano:/export/src/cpython# vi 1.p^C
root@piano:/export/src/cpython# /export/python3/bin/python3 ./1.py foo
10.402687549591064
root@piano:/export/src/cpython# python2.7 ./1.py
10.0434100628
Any difference doesn't seem to be distinguishable from noise on my system.
If I run this:
from __future__ import print_function
import os
import sys
import time
def getoutput(cmd):
# Hand-crafted variant
if len(sys.argv) >1:
import shlex, tempfile
f, fpath = tempfile.mkstemp()
status = os.system("{ " + cmd + "; } >" +
shlex.quote(fpath) + " 2>&1")
with os.fdopen(f, "r") as tfile:
output = tfile.read()
os.unlink(fpath)
if output[-1:] == '\n':
output = output[:-1]
return output
else:
import subprocess
p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,
stderr=None, close_fds=True)
return p.communicate()[0]
t = time.time()
for file in getoutput("find /usr/bin -type f 2>/dev/null").decode().split('\n'):
diff = getoutput("/usr/bin/objdump '%s' 2>/dev/null" % file)
then I get more variation than can be measured by changing close_fds.
Running something similar (no decode()) under python 2.7 is *slower* than
python3.
So, something other than closefrom() is going on here.
--
title: subprocess.Popen() is extremely slow (with close_fds=True which is the
default) on Illumos -> subprocess.Popen() is sometimes slower in python3 under
illumos
___
Python tracker
<https://bugs.python.org/issue37790>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
John Levon added the comment: I would strongly suggest those of you who are not "getting it" to actually try Jesus's patch out in some real scenarios. You'll quickly see what the benefit is. I think some of you are missing that it's a *not* just about performance: it's a system comprehension tool. It's there to help answer questions, on a live system; sometimes those are performance questions, but more often they're *not*. I can't speak as to the maintenance burden. I'm sure we can all agree that the ceval.c changes are not pretty - it's why I never submitted my original changes. But speaking for the Solaris organization, the burden of maintaining our patches across the various Python releases has been minimal. -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked
John Levon added the comment: Any progress on this regression? A patch is available... thanks. -- ___ Python tracker <http://bugs.python.org/issue1975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked
John Levon added the comment: The spec broken is here: http://docs.python.org/library/signal.html Namely: # Some care must be taken if both signals and threads are used in the same program. The fundamental thing to remember in using signals and threads simultaneously is: always perform signal() operations in the main thread of execution. Any thread can perform an alarm(), getsignal(), pause(), setitimer() or getitimer(); only the main thread can set a new signal handler, and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads). This means that signals can’t be used as a means of inter-thread communication. Use locks instead. -- ___ Python tracker <http://bugs.python.org/issue1975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked
John Levon added the comment: I still do not understand the objection you have to the simple patch which restores old behaviour, works the same across all OSes, and doesn't require new APIs. What is the objection? -- ___ Python tracker <http://bugs.python.org/issue1975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked
John Levon added the comment: To quote Andriy in the first comment: "It doesn't bring any visible changes to readline behavior either." Are you saying this is not the case? -- ___ Python tracker <http://bugs.python.org/issue1975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1759169] clean up Solaris port and allow C99 extension modules
John Levon added the comment: > However, experience tells that systems can break in surprising ways > if the system headers are compiled with different defines. This is indeed a reasonable concern (for which the best solution is dropping the defines in the Python compile). > I do feel this restrictiveness of the header files (wrt. C99) is > arbitrary, and has no use. Unfortunately, neither you, I, nor Sun can do anything at all about this fact. I've filed an RFE for you: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6806390 feature_tests.h could be laxer about C99 (It'll take a while to be visible externally.) Even if this happens, though, it's strictly a workaround: it is still a bug that Python sets these defines on Solaris: they do not mean what the Python build thinks they mean. It's effectively a Linux-ism. > setting _XOPEN_SOURCE had worked fine since Solaris 7. The particular change we're talking about (C99) went back in 2003: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4760794 4760794 UNIX03: sys/feature_tests.h updates required to support SUSv3 and c99 so Python has been broken by this for all of the Solaris 10 lifecycle. ___ Python tracker <http://bugs.python.org/issue1759169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked
John Levon added the comment: Surely readline is irrelevant anyway. The Python spec guarantees behaviour, and that guarantee is currently broken. ___ Python tracker <http://bugs.python.org/issue1975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
John Levon added the comment: Robert, I have no idea how Mac OS does pstack helpers without generating object files, sorry. > no simply pid$target:a.out:: probes available. Hmm. Try adding -Z to see if that helps. > /Users/rkern/hg/Python-2.5.4/Include/phelper.d: line 110: relocation > remains against user symbol D``PyEval_EvalFrameEx (offset 0x5) This is trying to tell you that there's no such function. Indeed, this isn't mentioned in my original patches, have you been editing it? -- ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
John Levon added the comment: Yes, my mistake. I noticed this typo in the original patch: 207 +PyObject * 208 +PyEval_EvalFrameexEx(PyFrameObject *f, int throwflag)) Can you: - verify that HAVE_DTRACE is indeed defined for ceval.c - do an nm on ceval.o and look which Eval* functions you do have Somehow, PyEval_EvalFrameEx seems not to be ending up in the .o file. It should be easy for you to work out why... -- ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8864] multiprocessing: undefined struct/union member: msg_control
John Levon added the comment: This appears to be one of the few cases where there's incompatibilities between different versions of the standards. Old BSD sockets use msg_accrights*, whereas the more modern way is msg_control* pointing to a struct cmsghdr. In terms of user/kernel interface, this difference is encoded as a MSG_XPG4_2 flag via a __xnet_recvmsg() re-define depending upon #ifdef _XPG4_2. The result being that it's impossible to use C99 and a modern struct msghdr together. This is less than ideal and I'm following it up internally. In terms of getting Python building again, it should be sufficient to define _XPG4_2 for the multiprocessing module compile only. -- ___ Python tracker <http://bugs.python.org/issue8864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8864] multiprocessing: undefined struct/union member: msg_control
John Levon added the comment: Right, it should be one of the "official" ways of enabling that. -- ___ Python tracker <http://bugs.python.org/issue8864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8864] multiprocessing: undefined struct/union member: msg_control
John Levon added the comment: defining _XOPEN_SOURCE=600 or similar is better, as Martin pointed out. -- ___ Python tracker <http://bugs.python.org/issue8864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8864] multiprocessing: undefined struct/union member: msg_control
John Levon added the comment: Yes, we would almost certainly want something similar. -- ___ Python tracker <http://bugs.python.org/issue8864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8864] multiprocessing: undefined struct/union member: msg_control
John Levon added the comment: It's not clear why you'd need configure tests, but you could easily add the define in the body of the autoconf test AFAIK - is there a reason this is difficult? -- ___ Python tracker <http://bugs.python.org/issue8864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4434] Embedding into a shared library fails
John Levon added the comment: Terry, what in the above discussion leads you to believe there is no bug? The original complaint "Python cannot be embedded in shared library due to dependency problems with lib-dynload" is still valid. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue4434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
