[Haskell-cafe] Haskell and concurrency

[Graham Klyne]

[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