Well, select() is discouraged for non-blocking IO, because there are other ways of doing it. The best way on windows is to use IO Completion ports, where you associate a socket with such a port and then wait for completion. There are many different ways to use that model. For example, have all the sockets share a single port and then check it regularly (by blocking or polling it). This is effectively the same as using select(), except that is scales better. There is no expensive setting up of file descriptors for the call, and no maximum number of sockets. (512 for select on windows, I think) Another way is to have a thread from the windows threadpool call a callback once an IO event on the port completes, and this is what we use in StacklessIO. This enables us to set certain flags within python immediately and wake up the blocking tasklets as soon as possible.
As for why we want to do non-blocking IO, well, a server may have to do other stuff than _only_ respond to network events. In the case of EVE, it is a game and it runs a game loop. We try to make it run the simulation loop at least 20 times a second. It does this, even if there is no socket IO. Sometimes, we _do_ actually block. We maintain a queue of scheduled internal events and if not much is happening in the simulation, we will use the windows WaitForMultipleObjects() sleep function with a delay. Any IO will break that sleep loop. It is another feature of StacklessIO that it maintains a windows Event object, that the user can use to break out of such wait calls in the event of IO Completion. StacklessIO is currently deployed and is handling some 3000 client socket connections on a single thread for each proxy, while running a program loop. Cheers, Kristján From: Larry Dickson [mailto:[email protected]] Sent: 16. júlí 2009 14:23 To: Kristján Valur Jónsson Cc: Henning Diedrich; [email protected] Subject: Re: [Stackless] irc threads This is interesting - your reference notes that select is discouraged for NON-BLOCKING IO, which it seems to me forces you into polling mode, which is always bad - not only because of busy resource use, but also because of slowness of response since one presumably chains everything off the timer in this case. As for scaling badly, timer ticks that have to check everything every time have the same problem - and there are ways of making an n-fold select loop have n log n overhead instead of n squared. What I'm seeing in these Windows notes is "not seeing the forest for the trees" in questions of responsive event programming with multiple inputs. I suspect that, hiding behind it all, the idea that you can have a separate thread for each event is still lurking, but that is only OK if the threads hardly ever share data or timing. The prevalence of non-blocking IO, a.k.a. busy loop, just makes me scratch my head. That just means someone has not finished designing the program. Larry On 7/15/09, Kristján Valur Jónsson <[email protected]<mailto:[email protected]>> wrote: Also, I'd like to add that we don't generally want to block, even for select(). In our framework, the application may have numerous tasks to do when it is not servicing IO. This necessitates using select to poll all the sockets, with the associated setup overhead. select() as such is recognized as scaling badly, even on unix() which is why (I've been told) there are now alternatives for asynchronous IO commonly available on linux. K From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Kristján Valur Jónsson Sent: 14. júlí 2009 23:08 To: Larry Dickson Cc: Henning Diedrich; [email protected]<mailto:[email protected]> Subject: Re: [Stackless] irc threads Well, on Windows, one of the rules of efficient network programming is to not use select(). See: http://tangentsoft.net/wskfaq/articles/io-strategies.html and http://msdn.microsoft.com/en-us/magazine/dvdarchive/cc302334.aspx select() is discouraged on windows except for compatibility reasons, since it works contrary to the internal IO scheduling mechanisms. K From: Larry Dickson [mailto:[email protected]<mailto:[email protected]>] Sent: 14. júlí 2009 15:34 To: Kristján Valur Jónsson Cc: Henning Diedrich; [email protected]<mailto:[email protected]> Subject: Re: [Stackless] irc threads There seems to be a false assumption here: select does not "poll the sockets" (or anything else) and it is not inefficient. In fact, it blocks until one of the events in question takes place, then reawakens a single process (e.g. main tasklet). This is as efficient as you can get, and "native facilities" are almost certainly just doing the same thing in a hidden place. Larry Dickson Cutting Edge Networked Storage On 7/9/09, Kristján Valur Jónsson <[email protected]<mailto:[email protected]>> wrote: StacklessIO is written in C++. It uses native facilities to notify an internal event queue when an IO request has completed, instead of requiring the "main tasklet" to regularly poll the sockets using select() which is inefficient. This aims to minimize latency and reduce overhead. It can also use the async. notification facility of the python C api to wake up sleeping tasklets without requiring the main tasklet to poll the event queue. It is also more 'complete' in its emulation of the native socket module, I think. But performance tests by Richard on his module have still shown it to be very capable, and to scale better than threaded solutions like your irc server, so it may well be quite adequate for the task. K > -----Original Message----- > From: Henning Diedrich > [mailto:[email protected]<mailto:[email protected]>] > Sent: 9. júlí 2009 14:02 > To: Kristján Valur Jónsson; > [email protected]<mailto:[email protected]> > Subject: Re: [Stackless] irc threads > > > > Kristján Valur Jónsson wrote: > > Yes, stacklessIO is designed to do that for you, to provide a > transparently tasklet-blocking replacement module for socket and > others. > > However, I hven't still managed to release it (although I do intend > to as soon as I can) and it is at them moment Windows only, and likely > to remain so for a bit. > > > > Meanwhile, there is Richard Tew's async socket implementation. > > > > K > > > > Thanks for the clarification. What is the difference between > stacklessIO > and Richard's implementation? This question is probably naive but maybe > some pointers are possible? > > Thanks, > Henning _______________________________________________ Stackless mailing list [email protected]<mailto:[email protected]> http://www.stackless.com/mailman/listinfo/stackless
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
