Re: Why no select in luasocket ?

["Cary O'Brien" <cobrien@...>]

> 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.
> > 

[snip]

> 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
> happens. 

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 [1].
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.
> 

Yuck.

[snip]

[1] Well, not exactly fileevents, but the C library for that particular
protocol had callbacks that work exactly loke file events.

-- cary 

> > > > 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.
>