Adam Olsen wrote:
> That brings you back to how you access the flags variable.
The existing signal handler sets a flag, doesn't it?
So it couldn't be any more broken than the current
implementation.
If we get too paranoid about this, we'll just end
up deciding that signals can't be used for anyt
Gustavo Carneiro wrote:
> The only potential problem left is that, by changing the pipe file
> descriptor to non-blocking mode we can only write as many bytes to it
> without reading from the other side as the pipe buffer allows. If a
> large number of signals arrive very quickly, that buffer ma
On 9/11/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Gustavo Carneiro wrote:
> > The only potential problem left is that, by changing the pipe file
> > descriptor to non-blocking mode we can only write as many bytes to it
> > without reading from the other side as the pipe buffer allows. If a
> >
Mihai Ibanescu wrote:
> Given that it doesn't seem to be the case, and my quick look at the code
> indicates that even internally python is inconsistent, should I file a
> low-severity bug so we don't lose track of this?
I'd say so, yes. A function whose refcount behaviour
differs when it fails i
On 9/11/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 9/11/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > This much would allow a GUI's poll loop to wake up when there is a
> > signal, and give control back to the python main loop, which could
> > then read off the signals and queue up their
On Sun, Sep 10, 2006 at 07:35:59PM +1200, Greg Ewing wrote:
> Barry Warsaw wrote:
> > I just want to point out that the C API documentation is pretty
> > silent about the refcounting side-effects in error conditions (and
> > often in success conditions too) of most Python functions. For
> >
Please log a bug - this is probably something suitable for fixing in 2.5.1. At
the very least, if it's going to be limited to 127 characters, it should
check that and raise a more suitable exception.
___
Python-Dev mailing list
Python-Dev@python.org
h
[Eric V. Smith]
> [I hope this belongs on python-dev, since it's about the design of
> something. But if not, let me know and I'll post to c.l.py.]
>
> I'm willing to file a bug report and patch on this, but I'd like to know
> if it's by design or not.
>
> In datetimemodule.c, the function wrap_st
[I hope this belongs on python-dev, since it's about the design of
something. But if not, let me know and I'll post to c.l.py.]
I'm willing to file a bug report and patch on this, but I'd like to know
if it's by design or not.
In datetimemodule.c, the function wrap_strftime() insists that the
On 9/11/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Now on to my new proposal. I do still use write(). If you can't
> accept that I think we should rip signals out entirely, just let them
> kill the process. Not a reliable feature of any OS.
>
> We create a single pipe and use it for all signals
Ok, I haven't heard back from Martin, but I'm going to hope he's OK with
tomorrow as a release date for 2.5rc2. If he's not, we'll try for the day
after. In any case, I'm going to declare the release25-maint branch FROZEN as
at 00:00 UTC on the 12th. That's about 12 hours from now.
This is for
On 11 Sep 2006, at 09:34, Neal Norwitz wrote:
> Michael,
>
> In Python/pystate.c, you made this checkin:
>
> """
> r39044 | mwh | 2005-06-20 12:52:57 -0400 (Mon, 20 Jun 2005) | 8 lines
>
> Fix bug: [ 1163563 ] Sub threads execute in restricted mode
> basically by fixing bug 1010677 in a non-brok
Michael,
In Python/pystate.c, you made this checkin:
"""
r39044 | mwh | 2005-06-20 12:52:57 -0400 (Mon, 20 Jun 2005) | 8 lines
Fix bug: [ 1163563 ] Sub threads execute in restricted mode
basically by fixing bug 1010677 in a non-broken way.
"""
_PyGILState_NoteThreadState is declared as static
13 matches
Mail list logo
