On 16 Feb, 06:30 pm, [EMAIL PROTECTED] wrote:
>I suggest it is possible to implement a PerfectReactor.
I don't think this constitutes a sufficient existence proof. Perhaps you could
write a prototype? There are a bunch of existing reactors you could either
import or copy/paste from to bootst
[EMAIL PROTECTED] wrote:
> When you boil it down, Twisted's event loop is just a notification for
> "a connection was made", "some data was received on a connection", "a
> connection was closed", and a few APIs to listen or initiate different
> kinds of connections, start timed calls, and commu
> As others have reported: if you have a gtk reactor and a wx reactor to
> support, in addition to a "regular" Win32 reactor (e.g. PythonWin),
> your approach still won't work. They all do GetMessage behind the
> scenes (sp?), yet you would run them in multiple threads, so they get
> their own
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Larry Hastings schrieb:
> > Oof! I'm embarrassed to have forgotten that. But that's not a fatal
> > problem. It means that on Windows the PerfectReactor must service the
> > blocking GetMessage loop, and these other threads notify the
> > Per
Larry Hastings schrieb:
> Oof! I'm embarrassed to have forgotten that. But that's not a fatal
> problem. It means that on Windows the PerfectReactor must service the
> blocking GetMessage loop, and these other threads notify the
> PerfectReactor of new events by sending a message.
...
> I'd
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>
> On Thu, 15 Feb 2007 13:55:31 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> >Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> > [snip]
> >>
> >> Now if we can only figure out a way for everyone to benefit from this
> >> without
> >> tyin
On Thu, 15 Feb 2007 13:55:31 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> [snip]
>>
>> Now if we can only figure out a way for everyone to benefit from this without
>> tying too many brains up in knots. :)
>
>Whenever I need to deal with these
Martin v. Löwis wrote:
> That is insufficient. The gtk main loop has more input
> sources than just the connection to X:
> - timers
> - idle handlers
> - child handlers
> - additional file descriptors
> - a generalzed 'event source'
When gtk is not the central event mechanism, there's no
need to
> On Thu, 15 Feb 2007 10:46:05 -0500, "A.M. Kuchling" <[EMAIL PROTECTED]> wrote:
> >It's hard to debug the resulting problem. Which level of the *12*
> >levels in the stack trace is responsible for a bug? Which of the *6*
> >generic calls is calling the wrong thing because a handler was set up
>
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Feb 2007 02:36:22 -0700, Andrew Dalke <[EMAIL PROTECTED]> wrote:
[snip]
> >2) asyncore is
> >smaller and easier to understand than Twisted,
>
> While I hear this a lot, applications written with Twisted _are_ shorter and
> contain less i
On 2/15/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> >> Ah, threads :-( It turns out that you need to invoke GetMessage in the
> >> context of the thread in which the window was created. In a different
> >> thread, you won't get any messages.
> >
> > I'd be interested to hear about other situ
>> Ah, threads :-( It turns out that you need to invoke GetMessage in the
>> context of the thread in which the window was created. In a different
>> thread, you won't get any messages.
>
> I'd be interested to hear about other situations where threading would
> cause a problem. My suspicion is
Martin v. Löwis wrote:
> Now, for these generalized event loops, it may not be possible anymore
> to combine all event sources into a single blocking call.
Right, that's why my proposal assumed that each disparate event source
would need its own thread.
> Ah, threads :-( It turns out that you
Larry Hastings schrieb:
> Bob Ippolito wrote:
>> There is no single PerfectReactor. There are several use cases where
>> you need to wait on >1 different event systems, which guarantees at
>> least two OS threads (and two event loops). In general it's nice to
>> have a single Python event loop ("th
Bob Ippolito wrote:
> There is no single PerfectReactor. There are several use cases where
> you need to wait on >1 different event systems, which guarantees at
> least two OS threads (and two event loops). In general it's nice to
> have a single Python event loop ("the reactor") to act on said thr
On Thu, 15 Feb 2007 10:46:05 -0500, "A.M. Kuchling" <[EMAIL PROTECTED]> wrote:
>On Thu, Feb 15, 2007 at 09:19:30AM -0500, Jean-Paul Calderone wrote:
>> >That feels like 6 layers too many, given that
>> > _logrun(selectable, _drdw, selectable, method, dict)
>> > return context.call({ILogContext: new
On Thu, Feb 15, 2007 at 09:19:30AM -0500, Jean-Paul Calderone wrote:
> >That feels like 6 layers too many, given that
> > _logrun(selectable, _drdw, selectable, method, dict)
> > return context.call({ILogContext: newCtx}, func, *args, **kw)
> > return self.currentContext().callWithContext(ctx, func
On Thu, 15 Feb 2007 02:36:22 -0700, Andrew Dalke <[EMAIL PROTECTED]> wrote:
>I was the one on the Stackless list who last September or so
>proposed the idea of monkeypatching and I'm including that
>idea in my presentation for PyCon. See my early rough draft
>at http://www.stackless.com/pipermail/
On 2/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Thomas Wouters wrote:
>
> > *I* don't like the idea of something in the Python installation
> > deciding which reactor to use.
>
> I wouldn't mind if some way were provided of changing
> the reactor if you want. I'd just like to see a long
> ter
I was the one on the Stackless list who last September or so
proposed the idea of monkeypatching and I'm including that
idea in my presentation for PyCon. See my early rough draft
at http://www.stackless.com/pipermail/stackless/2007-February/002212.html
which contains many details about using Stac
Greg Ewing schrieb:
> On unix at least, I don't think it should be necessary
> to change gtk, only pygtk. If it can find out the file
> descriptor of the connection to the X server, it can
> plug that into the reactor, and then call
> gtk_main_iteration_do() whenever something comes in
> on it.
Th
Thomas Wouters schrieb:
> If all (or all-but-one) of them have a 'run one iteration' method, you
> can call that from the 'main' mainloop.
That doesn't really work (and neither do variations involving coroutines.
Either the 'run one iteration' method blocks until one even arrives,
in which case
On 2/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> When one is nested inside the other. This isn't a common need, but it's
> occasionally useful if you need to switch back and forth between blocking
> and non-blocking code. For example, suppose that you have some code that
> wants to offer a
Phillip J. Eby wrote:
> At 04:25 PM 2/15/2007 +1300, Greg Ewing wrote:
>> Phillip J. Eby wrote:
>>> peak.events, for example, lets you have multiple event loops running in
>>> the same or different threads.
>> Different threads is okay if you're willing to use threads,
>> but you might not. The re
Thomas Wouters wrote:
> *I* don't like the idea of something in the Python installation
> deciding which reactor to use.
I wouldn't mind if some way were provided of changing
the reactor if you want. I'd just like to see a long
term goal of making it unnecessary as far as possible.
> In any ca
Thomas Wouters wrote:
> If all (or all-but-one) of them have a 'run one iteration' method, you
> can call that from the 'main' mainloop.
But without some way of blocking until an event arrives
for *either* loop, you have to resort to some kind of
busy polling, which is not elegant.
--
Greg
At 04:25 PM 2/15/2007 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
>>peak.events, for example, lets you have multiple event loops running in
>>the same or different threads.
>
>Different threads is okay if you're willing to use threads,
>but you might not. The reason you're using an event loop
On Thu, 15 Feb 2007 16:18:40 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
> [snip]
>
>This is where my vision is fundamentally different:
>you shouldn't have to *make* a decision in the first
>place. All event-driven libraries should be made to
>use the same substrate on any given platform. Then
>t
On Thu, 15 Feb 2007 15:47:39 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>Steve Holden wrote:
>
>> If the borrowed code takes a reactor parameter then presumably the
>> top-level code can pass the appropriate reactor type in.
>
>Since there should only be one reactor at a time in
>any given applic
On 2/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
Phillip J. Eby wrote:
> peak.events, for example, lets you have multiple event loops
> running in the same or different threads.
Different threads is okay if you're willing to use threads,
but you might not. The reason you're using an event loop
Phillip J. Eby wrote:
> peak.events, for example, lets you have multiple event loops
> running in the same or different threads.
Different threads is okay if you're willing to use threads,
but you might not. The reason you're using an event loop
may well be precisely so that you *don't* have to u
On 2/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
I know that will be hard to do, but it's the only
way out of this mess that I can see.
That depends on what you consider messy about it. *I* don't like the idea of
something in the Python installation deciding which reactor to use. It's my
app
Thomas Wouters wrote:
> If the choice for
> reactor was made somewhere deep inside the library, how does it know to
> use the GTK reactor?
In my ideal world, there wouldn't actually be a gtk
reactor -- there would only be a Linux reactor, a
MacOSX reactor, a Windows reactor, etc. Things like
py
Steve Holden wrote:
> If the borrowed code takes a reactor parameter then presumably the
> top-level code can pass the appropriate reactor type in.
Since there should only be one reactor at a time in
any given application, it shouldn't have to be passed
in -- it could be held in a global variabl
On 12:31 am, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>> On 08:52 pm, [EMAIL PROTECTED] wrote:
>>
>> >When I last looked at twisted (that is several years ago), there were
>> >several reactors - win32reactor, wxreactor, maybe even more.
>>
>> Only the very top-most level decides which
On 2/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> On 08:52 pm, [EMAIL PROTECTED] wrote:
>
> >When I last looked at twisted (that is several years ago), there were
> >several reactors - win32reactor, wxreactor, maybe even more.
>
> Only the very top-most level decides
At 01:31 PM 2/15/2007 +1300, Greg Ewing wrote:
>To my mind, there shouldn't be a "reactor" object
>exposed to the application at all. There should just
>be functions for setting up callbacks. The choice of
>implementation should be made somewhere deep inside
>the library, based on what platform is
Greg Ewing wrote:
> [EMAIL PROTECTED] wrote:
>> On 08:52 pm, [EMAIL PROTECTED] wrote:
>>
>> >When I last looked at twisted (that is several years ago), there were
>> >several reactors - win32reactor, wxreactor, maybe even more.
>>
>> Only the very top-most level decides which reactor the applicat
[EMAIL PROTECTED] wrote:
> On 08:52 pm, [EMAIL PROTECTED] wrote:
>
> >When I last looked at twisted (that is several years ago), there were
> >several reactors - win32reactor, wxreactor, maybe even more.
>
> Only the very top-most level decides which reactor the application will use.
This is a
On 08:52 pm, [EMAIL PROTECTED] wrote:
>When I last looked at twisted (that is several years ago), there were
>several reactors - win32reactor, wxreactor, maybe even more.
Yes. That's intentional. Each of those systems offers its own event loop, and
each reactor implements the basic operations
[EMAIL PROTECTED] schrieb:
> On 02:20 am, [EMAIL PROTECTED] wrote:
>
>> If Twisted is designed so that it absolutely *has* to use its own
>> special event mechanism, and everything else needs to be modified
>> to suit its requirements, then it's part of the problem, not part
>> of the solution.
>
On 02:22 pm, [EMAIL PROTECTED] wrote:
>On Wed, Feb 14, 2007, [EMAIL PROTECTED] wrote:
>>
>> As I said, I don't have time to write the PEPs myself, but I might fix
>> some specific bugs if there were a clear set of issues preventing this
>> from moving forward. Better integration with the standard
On 03:32 pm, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>>When you boil it down, Twisted's event loop ...
>But that is exactly the problem I have with Twisted. For HTTP ...
>From that word on out, you have completely lost the pl
On Wed, Feb 14, 2007, [EMAIL PROTECTED] wrote:
>
> As I said, I don't have time to write the PEPs myself, but I might fix
> some specific bugs if there were a clear set of issues preventing this
> from moving forward. Better integration with the standard library
> would definitely be a big win for
On 02:20 am, [EMAIL PROTECTED] wrote:
>If Twisted is designed so that it absolutely *has* to
>use its own special event mechanism, and everything else
>needs to be modified to suit its requirements, then it's
>part of the problem, not part of the solution.
I've often heard this complaint, usually
45 matches
Mail list logo
