Op dinsdag 11-12-2007 om 17:03 uur [tijdzone -0800], schreef Guido van
Rossum:
> On Dec 11, 2007 4:54 PM, Jan Claeys <[EMAIL PROTECTED]> wrote:
> > Op vrijdag 07-12-2007 om 07:26 uur [tijdzone -0700], schreef Sean
> > Reifschneider:
> > > I would say that this is an optimization that helps a specif
[private]
On Fri, Dec 14, 2007, Guido van Rossum wrote:
> On Dec 14, 2007 2:12 PM, Aahz <[EMAIL PROTECTED]> wrote:
>> On Sat, Dec 08, 2007, [EMAIL PROTECTED] wrote:
>>> On 05:20 pm, [EMAIL PROTECTED] wrote:
The best solution I can think of is to add a new API that takes a
signal and a
On Dec 14, 2007 2:12 PM, Aahz <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 08, 2007, [EMAIL PROTECTED] wrote:
> > On 05:20 pm, [EMAIL PROTECTED] wrote:
> >>
> >>The best solution I can think of is to add a new API that takes a
> >>signal and a file descriptor and registers a C-level handler for that
>
On Sat, Dec 08, 2007, [EMAIL PROTECTED] wrote:
> On 05:20 pm, [EMAIL PROTECTED] wrote:
>>
>>The best solution I can think of is to add a new API that takes a
>>signal and a file descriptor and registers a C-level handler for that
>>signal which writes a byte to the file descriptor. You can then cre
On Dec 14, 2007 9:38 AM, Isaac Morland <[EMAIL PROTECTED]> wrote:
> > I think we successfully resolved this. Adam Olsen will produce a patch
> > that allows one to specify a single file descriptor to which a zero
> > byte will be written by the C-level signal handler. Twisted and PyGTK
>
> I'm surp
On Mon, 10 Dec 2007, Guido van Rossum wrote:
> I think we successfully resolved this. Adam Olsen will produce a patch
> that allows one to specify a single file descriptor to which a zero
> byte will be written by the C-level signal handler. Twisted and PyGTK
I'm surprised that the byte is zero,
On 12/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 12, 2007 2:42 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > But there's no excuse for using CPU when the application
> > truly isn't doing anything other than waiting for
> > something to happen.
>
> There are tons of situations wh
On Dec 12, 2007 2:42 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> But there's no excuse for using CPU when the application
> truly isn't doing anything other than waiting for
> something to happen.
There are tons of situations where polling is quite reasonable as logn
as it involves a sleep.
--
-
Guido van Rossum wrote:
> Hm, Apple and Microsoft don't seem to think so. They go out of their
> way to implement elaborate visual effects.
Well, that's a different issue -- assuming the visual
effect is something wanted, then the CPU required to
produce it isn't unnecessary.
But there's no excu
On Dec 11, 2007 11:00 PM, Andrew Bennetts <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On Dec 11, 2007 4:54 PM, Jan Claeys <[EMAIL PROTECTED]> wrote:
> > > Op vrijdag 07-12-2007 om 07:26 uur [tijdzone -0700], schreef Sean
> > > Reifschneider:
> > > > I would say that this is an optimiza
Guido van Rossum wrote:
> On Dec 11, 2007 4:54 PM, Jan Claeys <[EMAIL PROTECTED]> wrote:
> > Op vrijdag 07-12-2007 om 07:26 uur [tijdzone -0700], schreef Sean
> > Reifschneider:
> > > I would say that this is an optimization that helps a specific set of
> > > platforms, including one that I think w
On Dec 11, 2007 6:01 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > On Dec 11, 2007 4:54 PM, Jan Claeys <[EMAIL PROTECTED]> wrote:
> >
> >>Almost every laptop user would benefit from it, and even some desktop or
> >>server users might save on their electric power bill...
Guido van Rossum wrote:
> On Dec 11, 2007 4:54 PM, Jan Claeys <[EMAIL PROTECTED]> wrote:
>
>>Almost every laptop user would benefit from it, and even some desktop or
>>server users might save on their electric power bill...
>
>
> Do you have data to support this claim?
Even if it doesn't save
On Dec 11, 2007 4:54 PM, Jan Claeys <[EMAIL PROTECTED]> wrote:
> Op vrijdag 07-12-2007 om 07:26 uur [tijdzone -0700], schreef Sean
> Reifschneider:
> > I would say that this is an optimization that helps a specific set of
> > platforms, including one that I think we really care about, the OLPC
> >
Op vrijdag 07-12-2007 om 07:26 uur [tijdzone -0700], schreef Sean
Reifschneider:
> I would say that this is an optimization that helps a specific set of
> platforms, including one that I think we really care about, the OLPC
> which needs it for decreased battery use.
Almost every laptop user would
On 11/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 10, 2007 4:07 PM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > On 10/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > > Adam & I are now on #python-dev. Can you join?
> > >
> > > I think we successfully resolved
On Dec 10, 2007 4:07 PM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 10/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > > Adam & I are now on #python-dev. Can you join?
> >
> > I think we successfully resolved this. Adam Olsen will produce a patch
> > that allows one to specify a si
On 10/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > Adam & I are now on #python-dev. Can you join?
>
> I think we successfully resolved this. Adam Olsen will produce a patch
> that allows one to specify a single file descriptor to which a zero
> byte will be written by the C-level sign
On Dec 10, 2007 4:26 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Adam & I are now on #python-dev. Can you join?
>
> I think we successfully resolved this. Adam Olsen will produce a patch
> that allows one to specify a single file descriptor to which a zero
> byte will be written by the C-le
> Adam & I are now on #python-dev. Can you join?
I think we successfully resolved this. Adam Olsen will produce a patch
that allows one to specify a single file descriptor to which a zero
byte will be written by the C-level signal handler. Twisted and PyGTK
will have to coordinate about this file
On Dec 9, 2007 10:16 AM, <[EMAIL PROTECTED]> wrote:
> On 12:21 am, [EMAIL PROTECTED] wrote:
> >Anyway, I would still like to discuss this on #python-dev Monday.
> >Adam, in what time zone are you? (I'm PST.) Who else is interested?
>
> I'm also interested. I'm EST, but my schedule is very flexibl
On 12:21 am, [EMAIL PROTECTED] wrote:
>Anyway, I would still like to discuss this on #python-dev Monday.
>Adam, in what time zone are you? (I'm PST.) Who else is interested?
I'm also interested. I'm EST, but my schedule is very flexible (I'm on
IRC pretty much all day for work anyway). Just le
On Dec 8, 2007 6:54 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Dec 8, 2007 5:30 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Dec 8, 2007 5:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Hm... Does this mean you're *always* creating an extra thread to handle
> > > signals?
>
On Dec 8, 2007 5:30 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Dec 8, 2007 5:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Hm... Does this mean you're *always* creating an extra thread to handle
> > signals?
>
> Yup, Py_Initialize will do it.
That's unacceptable. It must be possible
On Dec 8, 2007 6:30 PM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 09/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Gustavo, at some point you suggested making changes to Python so that
> > all signals are blocked in all threads except for the main thread. I
> > think I'd be more i
On 09/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 3:57 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > >
> > > On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > On Dec 8, 2007 2
On Dec 8, 2007 5:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 3:57 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > >
> > > On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > On Dec
On Dec 8, 2007 3:57 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > On Dec 8, 2007 2:56 PM, <[EMAIL PROTECTED]> wrote:
> > > > On 05:20 pm, [EMAIL PROTECTED
On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Dec 8, 2007 2:56 PM, <[EMAIL PROTECTED]> wrote:
> > > On 05:20 pm, [EMAIL PROTECTED] wrote:
> > > >The best solution I can think of is to add a new API that
Guido van Rossum wrote:
> Does Unix even promise that a signal gets delivered twice if it gets
> sent quickly twice in a row?
No, it doesn't.
However, this doesn't necessarily mean that you can just
drop them when the pipe becomes full. If more than one
type of signal is sharing a pipe, you don'
On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Dec 8, 2007 2:56 PM, <[EMAIL PROTECTED]> wrote:
> > On 05:20 pm, [EMAIL PROTECTED] wrote:
> > >The best solution I can think of is to add a new API that takes a
> > >signal and a file descriptor and registers a C-level handler for
On Dec 8, 2007 2:56 PM, <[EMAIL PROTECTED]> wrote:
> On 05:20 pm, [EMAIL PROTECTED] wrote:
> >The best solution I can think of is to add a new API that takes a
> >signal and a file descriptor and registers a C-level handler for that
> >signal which writes a byte to the file descriptor. You can the
Guido van Rossum wrote:
> On Dec 8, 2007 9:55 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> On Dec 8, 2007 2:17 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> Adam, perhaps at some point (Monday?) we could get together on
> #python-de
Guido van Rossum wrote:
> On Dec 8, 2007 2:17 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> Adam, perhaps at some point (Monday?) we could get together on
>>> #python-dev and interact in real time on this issue. Probably even
>>> better on the phone. This offer is open
On 05:20 pm, [EMAIL PROTECTED] wrote:
>The best solution I can think of is to add a new API that takes a
>signal and a file descriptor and registers a C-level handler for that
>signal which writes a byte to the file descriptor. You can then create
>a pipe, connect the signal handler to the write en
On Dec 8, 2007 1:38 PM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Dec 8, 2007 9:57 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > > Which is the best solution? I think my patch fixes two problems: 1. the
> > > need to have
On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 9:57 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > On Dec 8, 2007 3:58 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > > > Not only that, but
On 12/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 9:55 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
>
> > > Hm. How about making that an option? I don't think on the OLPC XO this
> > > is a valid use case (end users never have a console where they
On Dec 8, 2007 9:57 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > On Dec 8, 2007 3:58 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > > Not only that, but pygtk is a generic module;
> >
> > What does "generic" mean in this con
On Dec 8, 2007 9:55 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On Dec 8, 2007 2:17 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> >> Guido van Rossum wrote:
> >>> Adam, perhaps at some point (Monday?) we could get together on
> >>> #python-dev and interact in real time
On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 9:20 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > The
> > handler must be written in C in order to avoid the race condition
> > referred to by Glyph (signals arriving after the signal check in the
> > VM main loop
> """
> 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.
>
> [1] https://bugzilla.redhat.com/bugzilla/process_bug.cgi
On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 3:58 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > Not only that, but pygtk is a generic module;
>
> What does "generic" mean in this context? Surely not that it applies
> to other libraries than GTK?
Well, actual
At 11:17 AM +0100 12/8/07, Johan Dahlin wrote:
>Guido van Rossum wrote:
>> Adam, perhaps at some point (Monday?) we could get together on
>> #python-dev and interact in real time on this issue. Probably even
>> better on the phone. This offer is open to anyone who is serious about
>> getting this r
At 2:01 AM -0800 12/8/07, Guido van Rossum wrote:
...
>I'm curious -- is there anyone here who understands why [Py]GTK is
>using signals anyway? It's not like writing robust signal handling
>code in C is at all easy or obvious. If instead of a signal a file
>descriptor could be used, all problems
On Dec 8, 2007 9:20 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The
> handler must be written in C in order to avoid the race condition
> referred to by Glyph (signals arriving after the signal check in the
> VM main loop but before the select()/poll() system call is entered
> will not be not
On Dec 8, 2007 3:58 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> Not only that, but pygtk is a generic module;
What does "generic" mean in this context? Surely not that it applies
to other libraries than GTK?
> who are we to forbid the usage
> of signals if python itself allows it? If we we
On Dec 8, 2007 2:17 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Adam, perhaps at some point (Monday?) we could get together on
> > #python-dev and interact in real time on this issue. Probably even
> > better on the phone. This offer is open to anyone who is serious ab
On 08/12/2007, Johan Dahlin <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > Adam, perhaps at some point (Monday?) we could get together on
> > #python-dev and interact in real time on this issue. Probably even
> > better on the phone. This offer is open to anyone who is serious about
> >
Guido van Rossum wrote:
> Adam, perhaps at some point (Monday?) we could get together on
> #python-dev and interact in real time on this issue. Probably even
> better on the phone. This offer is open to anyone who is serious about
> getting this resolved. Someone please take it -- I'm offering free
Adam, perhaps at some point (Monday?) we could get together on
#python-dev and interact in real time on this issue. Probably even
better on the phone. This offer is open to anyone who is serious about
getting this resolved. Someone please take it -- I'm offering free
consulting here!
I'm curious -
On Dec 7, 2007 2:35 PM, <[EMAIL PROTECTED]> wrote:
>
> On 02:48 pm, [EMAIL PROTECTED] wrote:
> >Not only that, but current python signal handling is not theorethically
> >async safe; there are race conditions in the Py_AddPendingCalls API,
> >and it
> >just happens to work most of the time.
[This
On 02:48 pm, [EMAIL PROTECTED] wrote:
>Not only that, but current python signal handling is not theorethically
>async safe; there are race conditions in the Py_AddPendingCalls API,
>and it
>just happens to work most of the time.
Twisted has encountered one such issue, described here:
http:/
On 07/12/2007, Sean Reifschneider <[EMAIL PROTECTED]> wrote:
>
> On Thu, Dec 06, 2007 at 10:55:12PM -0700, Adam Olsen wrote:
> >That's pretty much what issue1564547 does. I think there's two marks
>
> Good point, I hadn't seen that before.
>
> >* Using poll and fd's is pretty platform specific for
2007/12/7, Sean Reifschneider <[EMAIL PROTECTED]>:
> FYI: I have no real interest in this, a friend of mine is interested in
> this, just from a "why is powertop saying pygtk is waking up 10 times a
> second on my laptop?" standpoint. So I'm just trying to shepherd this.
As a Gnome user, I'm per
On Thu, Dec 06, 2007 at 10:55:12PM -0700, Adam Olsen wrote:
>That's pretty much what issue1564547 does. I think there's two marks
Good point, I hadn't seen that before.
>* Using poll and fd's is pretty platform specific for what should be a
>general-purpose API
I would say that this is an optim
On Thu, Dec 06, 2007 at 09:08:54PM -0800, Guido van Rossum wrote:
>Can you explain how Gtk uses signals and threads together? The
Me? No. I've updated the bug at gnome.org asking someone there to answer
this.
FYI: I have no real interest in this, a friend of mine is interested in
this, just fro
On Dec 6, 2007 9:56 PM, Sean Reifschneider <[EMAIL PROTECTED]> wrote:
> Overview (my reading of it):
>
>PyGTK wakes up 10x a second in it's main loop because signals may be
>delivered to another thread and will only get picked up if the mainloop
>wakes up.
>
> In the following thread:
>
The OLPC project is also interested in getting this solved.
Can you explain how Gtk uses signals and threads together? The
combination strikes me as a recipe for disaster, but I'm probably
missing something.
--Guido
On Dec 6, 2007 8:56 PM, Sean Reifschneider <[EMAIL PROTECTED]> wrote:
> Overview
59 matches
Mail list logo
