[Python-Dev] The zombi thread of the Tcl library

2011-05-04 Thread Victor Stinner
Hi,

I have a question: would it be possible to mask all signals in the Tcl
thread? To understand the question, let's see the context...

I'm working on signals, especially on pthread_sigmask(), and I'm trying
to understand test_signal failures.

test_signal fails if the _tkinter module is loaded, because _tkinter
loads the Tcl library which create a thread waiting events in select().
For example, "python -m test test_pydoc test_signal" fails, because
test_pydoc loads ALL Python modules. I opened an issue for test_pydoc:
http://bugs.python.org/issue11995

_tkinter.c contains the following code:
#if 0
/* This was not a good idea; through  bindings,
   Tcl_Finalize() may invoke Python code but at that point the
   interpreter and thread state have already been destroyed! */
Py_AtExit(Tcl_Finalize);
#endif

Tcl_Finalize() exits the thread, but this function is never called in
Python. Anyway, it is not possible to unload a module implemented in C.

I would like to know if it would be possible to mask all signals in the
Tcl thread, or if Tcl supports/uses signals.

It is possible to mask all signals in the Tcl thread using:
--
allsignals = range(1, signal.NSIG)
oldmask = signal.pthread_sigmask(signal.SIG_BLOCK, allsignals)
import _tkinter
signal.pthread_sigmask(signal.SIG_SETMASK, oldmask)
--

I'm not asking the question for test_signal: I have a patch fixing
test_signal, even if the Tcl zombi thread is present (use pthread_kill()
to send the signal directly to the main thread).

(I wrote "zombi" thread because I was not aware that Tcl uses a thread,
nor that test_pydoc loads all modules. The thread is valid, alive, and
it's just a joke. The threads is more hidden than zombi.)

Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Borrowed and Stolen References in API

2011-05-04 Thread Mark Shannon

Hi,

The online documentation specifies which API function borrow and/or 
steal references (as opposed to the default behaviour).

Yet, I cannot find this information anywhere in the source.

Any clues as to where I should look?

Cheers,
Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Borrowed and Stolen References in API

2011-05-04 Thread Amaury Forgeot d'Arc
Hi,

Le mercredi 4 mai 2011, Mark Shannon  a écrit :
> The online documentation specifies which API function borrow and/or steal 
> references (as opposed to the default behaviour).
> Yet, I cannot find this information anywhere in the source.
>
> Any clues as to where I should look?

It's in the file Doc/data/refcounts.dat
in some custom format.

-- 
Amaury

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] The zombi thread of the Tcl library

2011-05-04 Thread Antoine Pitrou
On Wed, 04 May 2011 10:58:42 +0200
Victor Stinner  wrote:
> 
> Tcl_Finalize() exits the thread, but this function is never called in
> Python. Anyway, it is not possible to unload a module implemented in C.

You could expose Tcl_Finalize() for debug purposes and call it in
test_signal.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] The zombi thread of the Tcl library

2011-05-04 Thread Victor Stinner
Le mercredi 04 mai 2011 à 12:05 +0200, Antoine Pitrou a écrit :
> On Wed, 04 May 2011 10:58:42 +0200
> Victor Stinner  wrote:
> > 
> > Tcl_Finalize() exits the thread, but this function is never called in
> > Python. Anyway, it is not possible to unload a module implemented in C.
> 
> You could expose Tcl_Finalize() for debug purposes and call it in
> test_signal.

Good idea. I opened an issue with a patch implementing Tcl_Finalize():
http://bugs.python.org/issue11998

I also added a workaround _tkinter border effect in test_signal.
Buildbots look to be happy.

Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] New interest areas in Experts Index

2011-05-04 Thread Nick Coghlan
I just added two new interest areas in the Expert's Index [1]

context managers: for any issues relating to proposals to add context
management capabilities to objects in the stdlib, triagers should feel
free to add me to the nosy list
test coverage: this is specifically for anyone willing to help review
and commit test coverage improvement patches (rather than the more
general "testing" interest area that was already present)

Cheers,
Nick.

[1] http://docs.python.org/devguide/experts

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] cpython (2.7): Issue #11277: test_zlib tests a buffer of 1 GB on 32 bits

2011-05-04 Thread Antoine Pitrou
On Wed, 04 May 2011 21:27:50 +0200
victor.stinner  wrote:
> http://hg.python.org/cpython/rev/7f3cab59ef3e
> changeset:   69834:7f3cab59ef3e
> branch:  2.7
> parent:  69827:affec521b330
> user:Victor Stinner 
> date:Wed May 04 21:27:39 2011 +0200
> summary:
>   Issue #11277: test_zlib tests a buffer of 1 GB on 32 bits

What's the point? The issue with 2GB or 4GB buffers is that they cross
the potential limit of a machine type (a signed or unsigned integer).
I don't see any benefit in testing a 1GB buffer; the test could
probably be removed instead.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Borrowed and Stolen References in API

2011-05-04 Thread Greg Ewing

Mark Shannon wrote:

The online documentation specifies which API function borrow and/or 
steal references (as opposed to the default behaviour).

Yet, I cannot find this information anywhere in the source.


There are comments in some places, e.g. in listobject.h:

  *** WARNING *** PyList_SetItem does not increment the new item's reference
  count, but does decrement the reference count of the item it replaces,
  if not nil.  It does *decrement* the reference count if it is *not*
  inserted in the list.  Similarly, PyList_GetItem does not increment the
  returned item's reference count.

If you're looking for evidence in the actual code, there's
nothing particular to look for -- it's implicit in the
way the function works overall.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Borrowed and Stolen References in API

2011-05-04 Thread Greg Ewing

Amaury Forgeot d'Arc wrote:


It's in the file Doc/data/refcounts.dat
in some custom format.


However, it doesn't seem to quite convey the same information.
It lists the "refcount effect" on each parameter, but translating
that into the notion of borrowed or stolen references seems
to require knowledge of what the function does.

For example, PyDict_SetItem has:

PyDict_SetItem:PyObject*:p:0:
PyDict_SetItem:PyObject*:key:+1:
PyDict_SetItem:PyObject*:val:+1:

All of these parameters take borrowed references, but the
key and val get incremented because they're being stored
in the dict.

So this file appears to be of limited usefulness.

--
Greg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by

2011-05-04 Thread Ethan Furman

Victor Stinner wrote:

Le mardi 03 mai 2011 à 16:22 +0200, Nadeem Vawda a écrit :

On Tue, May 3, 2011 at 3:19 PM, victor.stinner
 wrote:

+# Issue #10276 - check that inputs of 2 GB are handled correctly.
+# Be aware of issues #1202, #8650, #8651 and #10276
+class ChecksumBigBufferTestCase(unittest.TestCase):
+int_max = 0x7FFF
+
[email protected](mmap, "mmap() is not available.")
+def test_big_buffer(self):
+if sys.platform[:3] == 'win' or sys.platform == 'darwin':
+requires('largefile',
+ 'test requires %s bytes and a long time to run' %
+ str(self.int_max))
+try:
+with open(TESTFN, "wb+") as f:
+f.seek(self.int_max-4)
+f.write("asdf")
+f.flush()
+try:
+m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
+self.assertEqual(zlib.crc32(m), 0x709418e7)
+self.assertEqual(zlib.adler32(m), -2072837729)
+finally:
+m.close()
+except (IOError, OverflowError):
+raise unittest.SkipTest("filesystem doesn't have largefile 
support")
+finally:
+unlink(TESTFN)
+
+

0x7FFF is (2G-1) bytes. For a 2GB buffer, int_max should be
0x8000. However, if you make this change, crc32() and adler32()
raise OverflowErrors (see changeset a0681e7a6ded).


I don't want to check OverflowError: the test is supposed to compute the
checksum of a buffer of 0x7FFF bytes


The comment says 'check that inputs of 2 GB are handled correctly' but 
the file created is 1 byte short of 2Gb.  Is the test wrong, or just 
wrongly commented?  Or am I not understanding?


~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com