[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Erlang implementation fun...



G'day Mike,

You're quite right in all your points. The thing is that Erlang uses
fancy non-posix things when they are available on the operating system
it's being built for, and then Erlang programs use them automatically.

Also, I suspect that I/O wouldn't be the bottleneck in a lot of other
languages if you tried to use a one process/thread per client model,
right? You can beat Erlang if you program in C, but you have to give
up your convenient blocking I/O interface, which Erlang programs can
keep (but of course Erlang is about more than that.)

> > Well, that's all just implementation details, so why does it matter 
> > whether it's POSIX or not? And I doubt that'd often be a problem unless 
> > you have a *LOT* of erlang systems cooperating in one network.
> 
> POSIX matters because its the lowest common denominator. If your Erlang
> implementation is written to POSIX, it'll work everywhere. If it makes
> use of kqueues, it will only run on FreeBSD. Erlang looked too serious
> to be a one-OS language.

Erlang uses kqueues when built on FreeBSD, and I think it has similar
things for other operating systems. It can also be built with 'kpoll'
support on Linux, which is a blood-and-guts highspeed poll()
replacement written by some Erlang programmers (Tony Rogvall and Per
Bergqvist) for more speed in Bluetail/Nortel networking products (and
others). kpoll is at http://www.synap.se/open_source.html (the current
version of Erlang can be ./configure'd to use this).

Since we sell our programs bundled as "appliances", we can do whatever
we want to the operating system thank-you-very-much :-)

I hope that answers some of your questions. I don't know what
platforms/configurations Joe used in his benchmarks so I can't say
more -- I doubt he used kpoll, though.

Cheers,
Luke