Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we can explicitly know which thread is executed,
main or not.
But from library it's not easy.
Tulip uses check like
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov andrew.svet...@gmail.com a écrit :
Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we can explicitly know which thread is executed,
2013/8/30 Andrew Svetlov andrew.svet...@gmail.com:
Tulip uses check like
threading.current_thread().name == 'MainThread'
You should use the identifier, not the name: threading.current_thread().ident.
This approach has a problem: thread name is writable attribute and can
be changed by
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov andrew.svet...@gmail.com a écrit :
Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we can explicitly know which thread is executed,
Le Fri, 30 Aug 2013 11:36:57 +0200,
Victor Stinner victor.stin...@gmail.com a écrit :
If we expose the identifier of the main thread, something should be
added to the threading module, not the signal module.
Agreed.
Is it possible that the main thread exit while there are still other
live
On Fri, Aug 30, 2013 at 12:24:07PM +0300, Andrew Svetlov
andrew.svet...@gmail.com wrote:
Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we can explicitly know which thread is
I missed _MainThread in threading, that's why I've guessed to add
function to signal module.
threading.main_thread() is much better sure.
On Fri, Aug 30, 2013 at 12:39 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov andrew.svet...@gmail.com a
_MainThread can be used as workaround, but adding public function makes value.
Oleg, as I understand _MainThread is a class, not class instance, test
for threading._MainThread.ident doesn't make sense.
On Fri, Aug 30, 2013 at 12:44 PM, Oleg Broytman p...@phdru.name wrote:
On Fri, Aug 30, 2013
I've filed http://bugs.python.org/issue18882 for this.
On Fri, Aug 30, 2013 at 12:52 PM, Andrew Svetlov
andrew.svet...@gmail.com wrote:
_MainThread can be used as workaround, but adding public function makes value.
Oleg, as I understand _MainThread is a class, not class instance, test
for
Hello,
This has been bothering me for years: why don't we properly handle
EINTR, by running registered signal handlers and restarting the
interrupted syscall (or eventually returning early e.g. for sleep)?
EINTR is really a nuisance, and exposing it to Python code is just pointless.
Now some
2013/8/30 Charles-François Natali cf.nat...@gmail.com
Hello,
This has been bothering me for years: why don't we properly handle
EINTR, by running registered signal handlers and restarting the
interrupted syscall (or eventually returning early e.g. for sleep)?
EINTR is really a nuisance,
Am 30.08.2013 11:39, schrieb Antoine Pitrou:
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov andrew.svet...@gmail.com a écrit :
Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we
On 30 August 2013 20:27, Andrew Svetlov andrew.svet...@gmail.com wrote:
I've filed http://bugs.python.org/issue18882 for this.
I don't actually object to the addition, but is there any way that
threading.enumerate()[0] *won't* be the main thread?
(subinterpreters, perhaps, but they're going to
On 30 August 2013 20:29, Charles-François Natali cf.nat...@gmail.com wrote:
Hello,
This has been bothering me for years: why don't we properly handle
EINTR, by running registered signal handlers and restarting the
interrupted syscall (or eventually returning early e.g. for sleep)?
EINTR is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 30.08.2013 01:24, schrieb Sturla Molden:
Do the numbers add up?
.005 defects in 1,000 lines of code is one defect in every 200,000
lines of code.
However they also claim that to date, the Coverity Scan service
has analyzed nearly
Le Fri, 30 Aug 2013 22:09:37 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
On 30 August 2013 20:27, Andrew Svetlov andrew.svet...@gmail.com
wrote:
I've filed http://bugs.python.org/issue18882 for this.
I don't actually object to the addition, but is there any way that
Le Fri, 30 Aug 2013 14:06:11 +0200,
Christian Heimes christ...@python.org a écrit :
Am 30.08.2013 11:39, schrieb Antoine Pitrou:
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov andrew.svet...@gmail.com a écrit :
Main thread is slightly different from others.
Signals can be
I've made a patch. It works except scenario described by Christian Heimes.
See details in http://bugs.python.org/issue18882
On Fri, Aug 30, 2013 at 3:21 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Fri, 30 Aug 2013 14:06:11 +0200,
Christian Heimes christ...@python.org a écrit :
Am
2013/8/30 Amaury Forgeot d'Arc amaur...@gmail.com:
I agree.
Is there a way to see in C code where EINTR is not handled?
EINTR can be returned on slow syscalls, so a good heuristic would be
to start with code that releases the GIL.
But I don't see a generic way apart from grepping for syscalls
On Fri, 30 Aug 2013 12:29:12 +0200
Charles-François Natali cf.nat...@gmail.com wrote:
Furthermore, the stdlib code base is not consistent: some code paths
handle EINTR, e.g. subprocess, multiprocessing, sock_sendall() does
but not sock_send()...
Just grep for EINTR and InterruptedError and
Hello,
On Fri, 30 Aug 2013 14:51:42 +0200 (CEST)
eli.bendersky python-check...@python.org wrote:
diff --git a/Doc/library/xml.etree.elementtree.rst
b/Doc/library/xml.etree.elementtree.rst
--- a/Doc/library/xml.etree.elementtree.rst
+++ b/Doc/library/xml.etree.elementtree.rst
@@ -105,37
On Fri, Aug 30, 2013 at 10:07 AM, Antoine Pitrou solip...@pitrou.netwrote:
Hello,
On Fri, 30 Aug 2013 14:51:42 +0200 (CEST)
eli.bendersky python-check...@python.org wrote:
diff --git a/Doc/library/xml.etree.elementtree.rst
b/Doc/library/xml.etree.elementtree.rst
---
I don't have a strong opinion on this either. The distinction between
send() and send_all() makes sense to me though (send_all() works hard to
get all your data out, send() only does what it can quickly).
Personally for calls like select() I think returning early on EINTR makes
sense, it's
On 8/30/2013 8:18 AM, Christian Heimes wrote:
By the way Coverity Scan doesn't understand Python code. It can only
analyzes C, C++ and Java code.
Have you (or Coverity) thought about which, if any, of the C defect
categories apply to Python? (Assuming no use of ctypes ;-). Would it
make any
ACTIVITY SUMMARY (2013-08-23 - 2013-08-30)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4182 (+14)
closed 26476 (+50)
total 30658 (+64)
Open issues
I still think non-blocking sounds network-related...
On Fri, Aug 30, 2013 at 12:23 PM, Eli Bendersky eli...@gmail.com wrote:
On Fri, Aug 30, 2013 at 10:07 AM, Antoine Pitrou solip...@pitrou.netwrote:
Hello,
On Fri, 30 Aug 2013 14:51:42 +0200 (CEST)
eli.bendersky
On 08/30/2013 06:37 PM, Ryan Gonzalez wrote:
I still think non-blocking sounds network-related...
Sometimes it is. And sometimes it's user-input related, or waiting on a local-pipeline related. But in all cases it
means, return whatever is ready, don't block if nothing is ready.
--
Hi all,
I think that PEP 450 is now ready for a PEP dictator. There have been a number
of code reviews, and feedback has been taken into account. The test suite
passes. I'm not aware of any unanswered issues with the code. At least two
people other than myself think that the implementation
On 8/30/2013 9:37 PM, Ryan Gonzalez wrote:
I still think non-blocking sounds network-related...
But it isn't ;-). Gui apps routinely use event loops and/or threads or
subprocesses to avoid blocking on either user input (which can come from
keyboard or mouse) and maybe disk operations and
If you've read my blog (eg: on planet python), you will be aware that
I dedicated August to full time email package development. At the
beginning of the month I worked out a design proposal for the remaining
API additions to the email package, dealing with handling message bodies
in a more
30 matches
Mail list logo
