Re: [Haskell-cafe] [Haskell] select(2) or poll(2)-like function?

Redirecting to haskell-cafe@, where this kind of long discussion belongs.
On Mon, Apr 18, 2011 at 9:07 AM, Colin Adams
On 18 April 2011 16:54, Ertugrul Soeylemez
wrote: Well, *someone* has to worry about robustness and scalability. Users notice when their two minute system builds start taking four minutes (and will be at my door wanting me to fix it) because something didn't scale fast enough, or have to be run more than once because a failing component build wasn't restarted properly. I'm willing to believe that haskell lets you write more scalable code than C, but C's tools for handling concurrency suck, so that should be true in any language where someone actually thought about dealing with concurrency beyond locks and protected methods. The problem is, the only language I've found where that's true that *also* has reasonable tools to deal with scaling beyond a single system is Eiffel (which apparently abstracts things even further than haskell - details like how concurrency is achieved or how many concurrent operations you can have are configured when you start an application, *not* when writing it). Unfortunately, Eiffel has other problems that make it undesirable.
I can't make a comparison, because I don't know Eiffel.
I do, and I don't recognize what the OP is referring to - I suspect he meant Erlang.
-- Colin Adams Preston, Lancashire, ENGLAND () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Don Stewart
Redirecting to haskell-cafe@, where this kind of long discussion belongs.
Answering to Mike Meyer here, because it has been requested multiple times that we move the discussion to the cafe. What you described about Eiffel didn't sound very different from what Haskell does, but in Haskell the OOP part is missing. You can very well pass MVars as arguments to a concurrent thread. This is the usual way to tell a thread to do something and wait for its answer. Of course you don't have to wait right away. You can command multiple threads to do something and then collect the answers pretty straightforwardly both with little programming and with little execution overhead. However, as STM gains more popularity you generally don't use the old fashioned command/wait concept. You would rather have a certain number of threads running all the time and communicating through transactions in variables. Threads with shorter lifetimes (for example for client connections) would not know about the other threads. They just know about the variables they need to use. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/
participants (2)
-
Don Stewart
-
Ertugrul Soeylemez