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
[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 communicate
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
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
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
term goal of
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 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: newCtx}, func,
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 threads
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
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 that
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 situations where
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 irrelevant
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 use
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 kinds of
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
tying too many brains up in
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: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 library
[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.
I've
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] 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 worry,
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 application will use.
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 which
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 reactor the
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 variable
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
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
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
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
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 application, it
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
they can
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
may
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
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
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 reason you're
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
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
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.
That is
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 of
38 matches
Mail list logo
