Re: RES: package system modification (module loaders)

[skaller <skaller@...>]

On Thu, 2005-01-20 at 23:20, Klaus Ripke wrote:
> Hi
> 
> On Thursday 20 January 2005 09:44, skaller wrote:
> > That is, you need to *schedule* coroutines that block,
> > so they're resumed when blocking operations will not block.
> >
> > In other words you need to do just what an operating
> > system does
> ... or is supposed to do.
> 
> If I get you right, however, you agree that doing this scheduling
> oneself instead of using OS supplied threads is the way to go
> (and you are doing it in felix)?

Doing the scheduling youself allows you to take advantage
of known structure of your application. This allows
a custom system to be very efficient. A general purpose
OS can't be so efficient because its general purpose.

Felix doesn't actually do any scheduling -- it just
makes the coroutines. You still have to write an application
specific scheduler, typically a C++ driver program would
do it. This is to allow embedding in an arbitrary architectural
framework.

Lua is the same -- it provides coroutines, but you still
have to organise them yourself.

So when people ask how the threading model works,
I basically say "well, there isn't one, you have to
design it yourself" -- again, same as Lua.

The orientation is different: Felix procedures read
data from a notional event queue with a 'read x' 
instruction, which they do by yielding and setting
a flag 'I want some data'. The driver then gets
data and stores it in 'x', and resumes the procedure
by calling its 'resume()' method, which causes it
to continue on after the 'read x' statement.

How the driver gets the data, and how it decides
which coroutine to give it to is indeterminate,
you have to write a driver yourself. EG dispatch
GUI events based on a coroutine for each window.

Lua coroutines aren't exactly the same: actually
they're more general I think (one reason I'm interested
in Lua).

> OS threads
> (besides virtually every implementation being broken in some ways)
> also have hefty limitations by design. One of them is stack usage with
> a typical (although usually customizable) 8MB per thread out of 1G,
> so you hit the roof at a mere 128 threads -- which is way to low for
> many applications.

Yes, precisely. Also context switching time is typically
linear in the number of threads, since choosing a thread
to run requires checking which one has blocked waiting
for data that is now available.

Cooperative threading as done by Felix or Lua can be
constant time (using for example a window number
in a GUI and a hashtable for lookup to find the associated
thread).

> So everything is fine with non-blocking lua sockets and select,
> isn't it?

Actually OS TCP/IP stacks are probably crap for particular
applications, such as web servers. If you have 100K connections,
'select' might get kind of slow .. :)

AFICS you actually have to use a raw socket and reimplement
half the TCP/IP stack to get around this: sockets are
just fine for half a dozen of them, but I doubt the OS
can cope with 100K of them.

Yet .. using a raw socket you notice there's only one
packet at a time coming in .. there's no reason you
can't do a web server that will support 100K simultaneous
connections. For example 100K Lua interpreters is quite
doable even on a 'small' box -- it's only N x 100K objects
on the heap, for N=10 that's only a million objects.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net