[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Why no select in luasocket ?
- From: "Cary O'Brien" <cobrien@...>
- Date: Sun, 4 Feb 2001 08:41:37 -0500 (EST)
> Diego Nehab wrote:
I wrote a while ago..
> > > > > Why isn't there select() in luasocket?
> > > > The only use of select by a script would to find out which of several
> > > > sockets is ready for a given operation, thus alowing multiplexing. The
> > > > library provides poll for that, and soon multi-threading within Lua will
> > > > render this use less important.
> > > Oh please, don't shoot pthreads at this. Is it that difficult to add
> > > for example a wait function that gets a list of sockets? Polling is
> > > nearly useless for anything but embedded systems or DOS. And timeouts
> > > add an artificial latency that only some applications may tolerate.
> Hmm... you don't like the interface... I made a different interface
> for some app. A register function that gets an fd and a callback function.
> And then a generic wait with only a timeout. The wait will select on
> all registered fds and will call the callback of the fd if something
This sort of event-driven interface is available in TCL (which also
has plain old select) . It is called "fileevent". You can set up
callbacks to run when the file is readable or writeable. This lets
you set up multi-threaded (sort of) programs without threads. TCL
handles the select loop. This originally came out of the requirements
of running TCL under X (i.e. TK), but I use it a lot for server
programs that have to manage multiple clients.
> Or another one: simulate an event queue. You register fds. The next-
> event function selects if no events are present and then builds events
> on the select result. (This version may get problems because it
> caches results.)
> The question is: is it easier to export select and make the register/wait
> in the highlevel or to implement it completely in C?
The fileevent interface and having the select loop in the interpreter
allows some incredible things to happen.
I have one very, very complex server implemented with fileevents .
I can start TCL from the command line, start the server from this
TCL session, and since the interpreter multiplexes both console and
application IO for me I can examine global data structures and run
functions from the command line WHILE THE SERVER IS RUNNING.
The event-driven framework in TCL is way beyond any other scripting
language, including Python and Perl.
But this is a lot of work to add to LUA probably.
> If you want something really different I guess you have to switch to
> asynch io and completion signals. But that's IMHO even uglier, less
> portable and much more difficult to implement.
 Well, not exactly fileevents, but the C library for that particular
protocol had callbacks that work exactly loke file events.
> > > > If there is anything you can't do with the current API, please clarify
> > > > and I will try to help.
> > > I only had a short look on luasocket but I would say: wait for any one
> > > of two sockets to become readable ;-)
> > That has already been said, by me. If you take better look, you will see
> > that LuaSocket was created mainly to be used on the client side. The
> > original idea was to provide support for for HTTP, SMTP and FTP.
> > Server-side support is being improved with time.
> For a single connection everything _is_ there. Select on one fd is like
> your poll. It's only necessary if you really want to handle multiple
> fds. That's what I wanted to say with "wait for two" ;) And trying to
> solve this with "read with small timeout and poll all others" is IMHO
> just an ugly hack.
> Ciao, ET.