[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANNOUNCE] luahttpd
- From: Joseph Stewart <joseph.stewart@...>
- Date: Tue, 11 Jan 2005 22:37:28 -0500
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