[concurrency] Common Concurrent Problems
pfein at pobox.com
Tue Jun 9 16:39:48 CEST 2009
On Jun 8, 2009, at 5:10 PM, Paul Boddie wrote:
> even made a remark on the "99 Concurrent Bottles of Beer" page which
> to have been wide of the mark - that one would surely try and use
> system features in the given example in order to provide a more
To clarify: my objective with this page is to give potential users a
general sense of what code using a variety of toolkits/libraries/
techniques looks like. The technical term for such a collection is a
chrestomathy: "a collection of similar programs written in various
programming languages, for the purpose of demonstrating differences in
syntax, semantics and idioms for each language" http://en.wikipedia.org/wiki/Program_Chrestomathy
AFAIC, such a collection is *not* the place for optimal solutions -
that would be appropriate a benchmark (something that's probably worth
doing as well). Accordingly, I'd encourage submitters to minimize
dependencies on external libraries (other than the toolkit being
demonstrated, obviously) and focus on clarity & comprehensibility for
> implementation - and I note that Glyph appears to regard the stated
> as not really being concurrent.
> How should we extend the problem on the Wiki to be something that
> doesn't have
> a workable serial solution?
The particular problem (tail | grep) came out of Beaz's class and was
incredibly helpful for comparing generators vs. coroutines. We
*should* find a problem that is actually concurrent - how about tail|
grep'ing multiple input files?
> Does anyone have any suggestions of more realistic problems, or are
> we back at the level of Wide Finder?
I don't see realism as the primary goal here - we could just use tail
& grep after all. ;-) That said, ideas for reasonable benchmarks
would be helpful - thoughts?
 I'm -0 on the use of time.sleep() & assuming input comes in full
More information about the concurrency-sig