I'm not sure I see any inherent problem in putting all I/O bound threads in some kind of FIFO queue. However, there still should be some mechanism that gives those threads priority over a CPU-bound thread that never wants to give up the GIL. A common OS solution is to simply have multiple FIFO queues, each with varying priorities. Threads with low priority don't get to run unless the higher priority queues are empty. One could probably try it with Python by simply having two queues (I/O and CPU) and separating threads into two categories depending on whether they are forcefully timed out or not. An OS would tend to have many more levels, but maybe just two queues would be enough to solve the thread scheduling problems being discussed here.
Cheers, Dave On Mar 17, 2010, at 6:01 AM, Kristján Valur Jónsson wrote: > I could also point you at EVE online, a large scale IO machine based on > stackless python. Our game proxies (front end servers) handle 30.000 client > connections each using tasklets. The problem is coarse grained scheduling of > IO and other tasks, same as with threads in regular Python. We have found > that adhering to FIFO scheduling provides good all round performance, > particularly the variance of IO latency is very low. > As I‘v mentioned in another message, I am toying with the idea of adding > another priority layer to the Stackless scheduler for IO tasks. It´s not > trivial though (requires me to do some stackless surgery) and the turnaround > time to test new approaches in production for us is a bit high J > > K > > From: python-dev-bounces+kristjan=ccpgames....@python.org > [mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On Behalf Of > Robert Hancock > Sent: 16. mars 2010 20:10 > To: Peter Portante > Cc: David Beazley; python-dev@python.org > Subject: Re: [Python-Dev] "Fixing" the new GIL > > The Linux kernel scheduler deals with two types of ratings and has a > heuristic algorithm that rewards and penalizes on a rapid basis. To > determine the next thread it inspects the priority array to find the highest > priority task that is runnable and then selects the first task in that > priority. This is a gross simplification of an extremely complex system, but > it is not simply a simple queue. > > To duplicate this exact type of scheduling in the interpreter would be a > daunting task, but Dave's example illustrates that some system of reward and > penalty can be beneficial. > > Peter has brought up the point, both here and at the Open Space at Pycon, > that before attempting a downsized version of the a priority thread scheduler > that we should look at other programs that have had to deal with similar > problems. > > Peter, since you have dealt with the nitty-gritty of concurrency before, can > you suggest some applications that could serve as models for research? > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
