[Haskell] select(2) or poll(2)-like function?
Mike Meyer
mwm at mired.org
Mon Apr 18 18:48:30 CEST 2011
On Mon, 18 Apr 2011 17:07:53 +0100
Colin Adams <colinpauladams at googlemail.com> wrote:
> On 18 April 2011 16:54, Ertugrul Soeylemez <es at ertes.de> 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.
No, I meant Eiffel. In particular, the Simple Concurrent Object
Oriented Programming system was described in OOSC but is "not yet part
of the official standard" (one of those "other problems" I
mentioned).
At the code level, you declared variables as referencing "separate"
objects, meaning their methods ran concurrently when invoked. These
declarations interacted with preconditions and method arguments, so
the compiler could deal with locks, wait conditions, and
synchronization behind the scenes.
Processors (i.e. - threads, or processes, or even processes on remote
systems) were assigned to the program when it started, and the RTS
dealt with assigning objects to processors and making sure the
communications worked properly.
<mike
--
Mike Meyer <mwm at mired.org> http://www.mired.org/consulting.html
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
More information about the Haskell
mailing list