| - A multi-threaded scheme ftpd that handles multiple connections -
| so I don't get those damn "I'm sorry, but we only allow 1.5
| connections from off campus at a time" messages anymore.
No, you get that message because those sites really do want to limit
the amount of network traffic they have to put up with. The unix
kernel does a much better job of multiprocessing than any user-mode
solution will be able to. Why complexify your ftp daemon when the
current arrangement is so simple and elegant: one process per
But if you do it one thread/connection, then as the load on the server
increases, it's *still* just one process as far as Unix's accounting goes.
So the net effect is that the cycles provided by a single process just
get divided up into smaller and smaller slices by the clients w/o increasing
the load on the system.
Needless to say, in either case a one megabyte scheme
runtime system makes this idea a non-starter, especially for
sites who are limiting network connections due to performance
Naah. I imagine an ftp server is primarily I/O bound. And the next release
of scsh (I hope) will have mechanisms for linking the initial image into the
VM's text pages. So the heap's will be small, and the byte codes will be
(a) shared between processes, and (2) unscanned by the GC.