On Saturday 02 September 2006 22:10, Gustavo Carneiro wrote:
According to [1], all python needs to do to avoid this problem is
block all signals in all but the main thread; then we can guarantee
signal handlers are always called from the main thread, and pygtk
doesn't need a timeout.
But I
Fredrik Lundh wrote:
That error mentioned in that post was in pythoncore module.
My error is while compiling pythoncore_pgo module.
iirc, that's a partially experimental alternative build for playing
with performance guided optimizations. are you sure you need
that module ?
Oh yes, it's
Gustavo Carneiro [EMAIL PROTECTED] writes:
According to [1], all python needs to do to avoid this problem is
block all signals in all but the main thread;
Argh, no: then people who call system() from non-main threads end up
running subprocesses with all signals masked, which breaks other
Gustavo Carneiro [EMAIL PROTECTED] wrote:
That's a very good point; I wasn't aware that child processes
inherited the signals mask from their parent processes.
That's one of the few places where POSIX does describe what happens.
Well, usually. You really don't want to know what happens when
Chris McDonough [EMAIL PROTECTED] wrote:
Would adding an API for sigprocmask help here?
No. sigprocmask is a large part of the problem.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: [EMAIL PROTECTED]
On Tuesday 05 September 2006 00:05, Nick Maclaren wrote:
Anthony Baxter isn't exaggerating the problem, despite what you may
think from his posting.
If the SF bugtracker had a better search interface, you could see why I have
such a bleak view of this area of Python. What's there now *mostly*
On 9/4/06, Nick Maclaren [EMAIL PROTECTED] wrote:
Gustavo Carneiro [EMAIL PROTECTED] wrote:
I am now thinking of something along these lines:
typedef void (*PyPendingCallNotify)(void *user_data);
PyAPI_FUNC(void) Py_AddPendingCallNotify(PyPendingCallNotify callback,
void
On Tuesday 05 September 2006 00:52, Gustavo Carneiro wrote:
3. Signals can be delivered to any thread, let's assume (because
of point #1 and not others not mentioned) that we have no control over
which threads receive which signals, might as well be random for all
we know;
Note that
On Mon, 04 Sep 2006 15:05:56 +0100, Nick Maclaren [EMAIL PROTECTED] wrote:
Gustavo Carneiro [EMAIL PROTECTED] wrote:
That's a very good point; I wasn't aware that child processes
inherited the signals mask from their parent processes.
That's one of the few places where POSIX does describe what
Gustavo Carneiro wrote:
OK, let's review what we know about current python, signals, and threads:
1. Python launches threads without touching sigprocmask;
2. Python installs signal handlers for all signals;
3. Signals can be delivered to any thread, let's assume (because
of
Gustavo Carneiro [EMAIL PROTECTED] wrote:
You guys are tough customers to please. I am just trying to solve a
problem here, not create a new one; you have to believe me.
Oh, I believe you.
Look at it this way. You are trying to resolve the problem that your
farm is littered with cluster
Jean-Paul Calderone wrote:
PyGTK would presumably implement its pending call callback by writing a
byte to a pipe which it is also passing to poll().
But doing that in a signal handler context invokes undefined behaviour
according to POSIX.
--
David Hopwood [EMAIL PROTECTED]
On Mon, 04 Sep 2006 17:24:56 +0100, David Hopwood [EMAIL PROTECTED] wrote:
Jean-Paul Calderone wrote:
PyGTK would presumably implement its pending call callback by writing a
byte to a pipe which it is also passing to poll().
But doing that in a signal handler context invokes undefined behaviour
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Mon, 04 Sep 2006 17:24:56 +0100,
David Hopwood [EMAIL PROTECTED]
der.co.uk wrote:
Jean-Paul Calderone wrote:
PyGTK would presumably implement its pending call callback by writing a
byte to a pipe which it is also passing to poll().
But
On Mon, 04 Sep 2006 18:18:41 +0100, Nick Maclaren [EMAIL PROTECTED] wrote:
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Mon, 04 Sep 2006 17:24:56 +0100,
David Hopwood [EMAIL PROTECTED]
der.co.uk wrote:
Jean-Paul Calderone wrote:
PyGTK would presumably implement its pending call callback
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
Thanks for expounding. Given that it is basically impossible to do
anything useful in a signal handler according to the relevant standards
(does Python's current signal handler even avoid relying on undefined
behavior?), how would you suggest
In GLib we have a child watch notification feature that relies on
the following signal handler:
static void
g_child_watch_signal_handler (int signum)
{
child_watch_count ++;
if (child_watch_init_state == CHILD_WATCH_INITIALIZED_THREADED)
{
write (child_watch_wake_up_pipe[1], B,
[Andreas Raab]
I'm curious if there is any interest in the Python community to achieve
better cross-platform math behavior. A quick test[1] shows a
non-surprising difference between the platform implementations.
Question: Is there any interest in changing the behavior to produce
identical
On 9/4/06, Nick Maclaren [EMAIL PROTECTED] wrote:
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Mon, 04 Sep 2006 17:24:56 +0100,
David Hopwood [EMAIL PROTECTED]
der.co.uk wrote:
Jean-Paul Calderone wrote:
PyGTK would presumably implement its pending call callback by writing a
byte
On 9/4/06, Gustavo Carneiro [EMAIL PROTECTED] wrote:
Now, we've had this API for a long time already (at least 2.5
years). I'm pretty sure it works well enough on most *nix systems.
Event if it works 99% of the times, it's way better than *failing*
*100%* of the times, which is what happens
On 8/18/06, Georg Brandl [EMAIL PROTECTED] wrote:
I'd like to commit this. It fixes bug 1542051.
Index: Objects/exceptions.c
...
Georg,
Did you still want to fix this? I don't remember anything happening
with it. I don't see where _PyObject_GC_TRACK is called, so I'm not
sure why
Gustavo,
Did you still want this addressed? Anthony and I made some comments
on the bug/patch, but nothing has been updated.
n
--
On 8/15/06, Gustavo Niemeyer [EMAIL PROTECTED] wrote:
If you have issues, respond ASAP! The release candidate is planned to
be cut this Thursday/Friday. There
There are 3 bugs currently listed in PEP 356 as blocking:
http://python.org/sf/1551432 - __unicode__ breaks on exception classes
http://python.org/sf/1550938 - improper exception w/relative import
http://python.org/sf/1541697 - sgmllib regexp bug causes hang
Does anyone
Tim Peters wrote:
Package a Python wrapper and see how popular it becomes. Some reasons
against trying to standardize on fdlibm were explained here:
http://mail.python.org/pipermail/python-list/2005-July/290164.html
Thanks, these are good points. About speed, do you have any good
24 matches
Mail list logo
