Re: [ANNOUNCE] luahttpd

[Joseph Stewart <joseph.stewart@...>]

On Tue, 11 Jan 2005 21:36:37 -0500, Javier Guerra <javier@guerrag.com> wrote:
> On Tuesday 11 January 2005 8:33 pm, Joseph Stewart wrote:
> > I also have been working on a lua httpd!
> 
> i'm sure it's a common wish... in fact i was surprised not to find dozens of
> these!
> 
> > Mine lacks the elegance of yours, but I'm trying to implement mine
> 
> (elegance? have you read the code?)

Well, at least your code is readable, uses Diego's url function and
has future "aspirations" (like POST, PUT, etc.) coded in... I tend to
just hack functions and if I can't remember how to use an existing
one, code my one.

> > strictly with coroutines, where a socket send or receive will yield
> > the thread to a scheduler that's heart is a select statement (blocking
> > on the very sends/receives in each thread).
> 
> i tried to do it with coroutines too (more lightweight), but luaSocket doesn't
> seem to have a truly nonblocking mode.  and i do like it's 'line mode'.

here's a sketch of mine:

master = socket.bind("*",PORT)
read_list = {master}
write_list = {}
thread_list = {}
while true do
  readable,writeable,error = socket.select(read_list, write_list, TIMEOUT)
  if error == "timeout" then
    -- do periodic tasks here such as checking to see
    -- if a coroutine needs to be resumed and
    -- discarding closed sockets
  end
  for _,which in readable do
    if which == master then
      client = master:accept()
      table.insert(read_list, client)
      thread_list[client] = create_thread(client)
    else
      coroutine.resume(thread_list[which])
    end
  end
end

> also, even if i think most of the queries could be answered quickly, some of
> them could try to use other blocking libraries (SQL?).  it wouldn't be nice
> to make all queries wait on one.

threading/forking is probably the safer, accepted way to do things...
i'm looking for a lighter-weight way of doing things, though...

> > Lua scripts started from the server would be sandboxed to prevent
> > crashing/hanging where possible, and provided a send() and receive()
> > function that "plays nice" with the scheduler.
> 
> i'm not fond of sandboxes... and it shows in my code, it's still too easy to
> break the whole thing.

i can understand how forking is safer, but are threads really any safer?

> > My code is monsterously nasty right now, but I'm hoping I can borrow
> > (steal) some ideas in your code and release it when it looks better.
> 
> sure... if your send() and receive() functions play nice enough, i'd like to
> do a coroutine based server, and let a handler to fork a thread if it needs
> to use blocking libraries

i'm just tinkering (no real project), so progress is spotty and slow,
but i'll share when i feel better about the implementation!

Thanks for kicking things off!

-j

> --
> Javier
> 
> 
> 


-- 
Person who say it cannot be done should not interrupt person doing it.
 -- Old Scottish Proverb