Hello, I noticed recently that there's an effort to show solutions to common concurrent problems on the python.org Wiki, and I've been using this effort as an excuse to look over my own work and to improve it in various ways. I even made a remark on the "99 Concurrent Bottles of Beer" page which appears to have been wide of the mark - that one would surely try and use operating system features in the given example in order to provide a more optimal implementation - and I note that Glyph appears to regard the stated problem as not really being concurrent.
http://wiki.python.org/moin/Concurrency/99Bottles In the next few days, I intend to release a new version of my pprocess library in order to more conveniently support problems like the one on the Wiki, but previous experience has shown that more compelling problems are required. Some time ago, the "Wide Finder" project attempted to document concurrency solutions for a log parsing problem which was regarded by some as being I/O-dominated, and for others led to optimised serial solutions that could outperform parallel solutions due to the scope for optimisation in most people's naive code. With pprocess, I bundle the PyGmy raytracer in order to demonstrate that multiple processes really do get used and can benefit programs on multiple cores, but I imagine that many people don't regard this as being "real world"-enough. How should we extend the problem on the Wiki to be something that doesn't have a workable serial solution? Does anyone have any suggestions of more realistic problems, or are we back at the level of Wide Finder? Paul _______________________________________________ concurrency-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/concurrency-sig
