Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #62677 > unrolled thread

Re: Using asyncio in event-driven network library

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Using asyncio in event-driven network library "Tobias M." <tm@tobix.eu> - 2013-12-24 16:41 +0100
    Re: Using asyncio in event-driven network library Christian Gollwitzer <auriocus@gmx.de> - 2013-12-25 14:52 +0100

#62677 — Re: Using asyncio in event-driven network library

Thanks for your answers! I didn't have the time to test any of your 
suggestions so far but they already gave me something to think about. At 
least now I'm much more clearer on what I am actually looking for.

On 23.12.2013 20:59, Terry Reedy wrote:
>
> What would be easiest for user-developers would be if someone were 
> able to wrap a gui loop in a way to give it the needed interface, so 
> the gui loop itself replaced and became the asyncio loop.
>
That's a good idea, maybe I will try this. On the other hand this means that
for every gui toolkit there must be a separate wrapper. I hoped this can 
be avoided.

On 23.12.2013 17:47, Chris Angelico wrote:
> You may be able to wrap your GUI code up so it fits inside asyncio.
> Rather than run a simple event loop, you could have your own loop that
> does some kind of checking: PyGTK has functions for peeking at events
> and doing just one iteration of the main loop, so you could pump all
> events with something like this:
>
> while gtk.events_pending(): gtk.main_iteration()
>
> No doubt other toolkits have something similar.
On 23.12.2013 20:59, Terry Reedy wrote:
> I think tk(inter) has 'run pending events' or something.
I didn't know functions like this exist in gui toolkits. Am I right in 
thinking that using these functions you don't have to use the built-in 
event loop. Instead you can write your own loop and just call 'run 
pending events' continuously?

I think what I actually want is the other way around. I want my library 
to be easy to use in existing gui applications that already have their 
own main loop. Their core should not need to be adapted for this. So I 
think I should provide a function like 'run pending events' in my api. 
For example in a PyQt application this could be called periodically by 
using a QTimer.

So I would use asyncio only if my library is used non-interactively with 
it's internal event loop.

Well, maybe I could reuse asyncio's transports and protocols in both 
situations. I don't know if they depend on asyncio's event loop.

Note: I didn't concern myself with all this stuff yet. Just wrote down 
what came to my mind. If there are any errors in my reasoning please 
correct me. I will try some approaches after the christmas holidays and 
get back to you then...

Thanks and regards,

Tobias

[toc] | [next] | [standalone]

#62704

Am 24.12.13 16:41, schrieb Tobias M.:
> On 23.12.2013 20:59, Terry Reedy wrote:
>> What would be easiest for user-developers would be if someone were
>> able to wrap a gui loop in a way to give it the needed interface, so
>> the gui loop itself replaced and became the asyncio loop.
>>
> That's a good idea, maybe I will try this. On the other hand this means
> that for every gui toolkit there must be a separate wrapper. I hoped this can
> be avoided.

To be done properly, it needs to be adapted for every toolkit. But the 
good news is, that it has already been achieved: IPython is able to 
integrate the readline library into all major GUI toolkits (%gui). Maybe 
you can rip off the code from there.

> On 23.12.2013 17:47, Chris Angelico wrote:
>> while gtk.events_pending(): gtk.main_iteration()
>>
>> No doubt other toolkits have something similar.
> On 23.12.2013 20:59, Terry Reedy wrote:
>> I think tk(inter) has 'run pending events' or something.

In Tk(inter) it is "update"

> I didn't know functions like this exist in gui toolkits. Am I right in
> thinking that using these functions you don't have to use the built-in
> event loop. Instead you can write your own loop and just call 'run
> pending events' continuously?

As Chris already explained, you then lose the advantages of the 
asynchronous operation. The reason behind the toolkits insisting on 
their main loop being run is, that they can wait for an event in a 
blocking way. Typically, under Linux, they call select() and on Windows 
WaitForMultipleObjects(), which blocks (sleeps) until an event arrives. 
Now to integrate your event source, you need to add it to this single 
blocking call.

Specifically, in the case of Tcl/Tk: The event loop is intrinsically 
able to wait for asynchronous IO from sockets, pipes, or serial lines to 
implement "fileevent". However, this is probably not useful since Python 
doesn't open files through Tcl's VFS layer. The easiest way is to run 
another thread, which waits in a blocking way, and to raise an event in 
the main thread. This is done from the C side by Tcl_ThreadQueueEvent() 
and Tcl_ThreadAlert() to wake up the event loop, or from the Tcl script 
level by the Threads package and sending a message to the main thread. 
Unfortunately this message queue stuff is quite complicated (it's 
described on the notifier man page 
http://www.tcl.tk/man/tcl/TclLib/Notifier.htm ). Further complication 
might come from the fact that some Linux distributions still ship with a 
Tcl that is not threads enabled. When I needed to add an unrelated event 
source, namely the events from GPIB devices, I simply used 
Tcl_AsyncProc() to do it, but I'm not sure whether this leads to race 
conditions.

	Christian

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web