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

Erlang implementation fun...



Folks,
I'm a little confused about something in Joe Armstrong's talk so I'm
hoping someone on this list could enlighten me. I got the impression
that Erlang uses user-level threads to run all Erlang threads within a
single OS process. I assume that all network IO is done asynchronously
using the poll system call. Does anyone know if that is actually true?

Assuming it is, how can Erlang programs with thousands of threads be
scalable? I had thought that network throughput slows dramatically when
using the poll system call for more than a few thousand clients; forcing
the kernel to iterate over a very long list of file descriptors when
almost all of them will have no activity is very time consuming. I know
of a few tricks that more or less fix the problem (/dev/poll on solaris,
kqueue on freebsd, IO completion ports on windows, the e_poll system
call on linux), but they're not exactly widely available and they're
definitely not POSIX.

My other question is whether Erlang offers any realtime garuntees. If
so, how do implementations manage interactions between the kernel's
scheduling garuntees and the Erlang scheduler garuntees?

Oh, thanks to everyone who presented at LL2 yesterday and thanks to the
organizers; you guys did an absolutely wonderful job. Thanks too to the
audience members who managed to be funny and informitive without
actually executing any of the presenters (i will not utter the dreaded
m-word in this place).

so-how-do-they-do-it-?-ly yours,
Mike