[Reminiscing mode] Recent discussions about Haskell concurrency remind me of a design I attempted some years ago for a real-time web content analyzer proxy (the sort of thing that companies would deploy to prevent their employees from downloading viruses from the web, etc.). The design was based on my (imperfect) understanding of lazy functional languages and their implementation (with some help from, SPJ's book), in particular using a graph-reduction model to evaluate a function like isSafe :: [octet] -> Bool The intent was that there could be an arbitrary and potentially very large number of concurrent web accesses passing through the proxy, so a thread-per-access could be unacceptably expensive, especially when each thread would most of the time be waiting for data. The advantage that I saw in the graph-reduction approach was that the current state of each evaluation would be entirely in the current expression graph, and there would be no per-transaction overhead other than the essential state information. The graph-reduction engine itself would have a number of worker threads, each of which would perform any graph reductions for which available incoming data was available -- a kind of demand-and-availability driven evaluation model. (The design was too ambitious to be implemented in the actual product, though it did spawn a company joke about Schonfinkel's device, and I understand that a number of ideas did eventually find their way into the implementation over time, but that's another story.) Anyway, I was wondering if any of the work on concurrent Haskell or concurrent functional programming addresses similar systems or ideas, in which implementation/hardware concurrency is decoupled from application concurrency requirements, and particularly with a view to applications requiring very low-overhead fine-grained concurrency? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact