Subject: event-driven programming (was Re: Archie-Clients )
To: Bakul Shah <email@example.com>
From: Perry E. Metzger <firstname.lastname@example.org>
Date: 01/28/1995 18:23:38
Bakul Shah says:
> > One kind of has to ask the question, then, why it hasn't been done.
> > I know many ftpd's now don't fork for "ls", but really, one server per
> > client is a pretty bad idea on a big ftp site.
> May be because each user has to have his own context? Each
> FTP user may have his own curren dir., may have used his own
> login acct. etc. Dealing with all that from a single ftpd
> will be pretty messy and *slow*!
Well, sort of. I've been working a lot recently with purely
event-driven programs that deal with tens (and occassionally hundreds)
of clients with purely callback-oriented programming styles. Provided
you have a context structure for each user, and are used to writing
code like this, in the end its no harder than any other style of
programming. Its remarkably easy and lightweight to deal with lots of
users, actually. select(2) is your friend.
There are some tasks -- like handling very large memory-mapped
databases of securities quotes (hmmm... I wonder where one would find
those :-) where this technique is very needed.
Now, as it turns out, the Xt library in the X distribution has a large
fraction of the tools you need to build such things, as ugly as that
sounds. Yes, I've written a bunch of code using Xt without displays to
provide an event-driven programming library, and it works very
nicely. There is a paper in the last Usenix workshop on applications
development by Jordan Hayes and Chuck Ocheret on these techniques --
they look ugly until you get used to them, at which point they seem